From mark at klomp.org  Sun Apr  1 01:05:45 2012
From: mark at klomp.org (Mark Wielaard)
Date: Sun, 1 Apr 2012 10:05:45 +0200
Subject: Configure changes for old build.sh autobuilder
Message-ID: <20120401080544.GA7342@toonder.wildebeest.org>

Hi,

Since zero and shark are both currently broken on 7 and have been for some
time, I have disabled them on the old build.sh builder for now.

icedtea6 now has cacao,jamvm,shark,zero enabled.
icedtea7 now has cacao,jamvm enabled.
icedtea-trunk has no additional runtimes enabled.

Cheers,

Mark
-------------- next part --------------
# HG changeset patch
# User Mark Wielaard <mark at klomp.org>
# Date 1333267331 -7200
# Node ID 05e41e1c037b4f0ba0b184bcf6fe57186aac5962
# Parent  f8891d3c2d23a71dfaba32fc06acf130e859f723
icedtea/build.sh: Enable zero for icedtea6, disable shark for icedtea7.

diff -r f8891d3c2d23 -r 05e41e1c037b icedtea/build.sh
--- a/icedtea/build.sh	Wed Mar 21 13:36:40 2012 +0100
+++ b/icedtea/build.sh	Sun Apr 01 10:02:11 2012 +0200
@@ -112,10 +112,10 @@
 
 # Some additional VMs only build against one or the other version.
 if [ "${VERSIONSTR}" == "6" ]; then
- ICEDTEA_ADDITIONAL_VMS="cacao,jamvm,shark"
+ ICEDTEA_ADDITIONAL_VMS="cacao,jamvm,shark,zero"
  ADDITIONAL_OPTIONS=""
 elif [ "${VERSIONSTR}" == "7" ]; then
- ICEDTEA_ADDITIONAL_VMS="shark"
+ ICEDTEA_ADDITIONAL_VMS="cacao,jamvm"
  ADDITIONAL_OPTIONS="--disable-system-lcms --disable-system-gio"
 else
  ICEDTEA_ADDITIONAL_VMS=""

From mark at icedtea.classpath.org  Sun Apr  1 01:05:45 2012
From: mark at icedtea.classpath.org (mark at icedtea.classpath.org)
Date: Sun, 01 Apr 2012 08:05:45 +0000
Subject: /hg/buildbot: icedtea/build.sh: Enable zero for icedtea6, disabl...
Message-ID: <hg.05e41e1c037b.1333267545.-8970262713663391652@icedtea.classpath.org>

changeset 05e41e1c037b in /hg/buildbot
details: http://icedtea.classpath.org/hg/buildbot?cmd=changeset;node=05e41e1c037b
author: Mark Wielaard <mark at klomp.org>
date: Sun Apr 01 10:02:11 2012 +0200

	icedtea/build.sh: Enable zero for icedtea6, disable shark for icedtea7.


diffstat:

 icedtea/build.sh |  4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diffs (16 lines):

diff -r f8891d3c2d23 -r 05e41e1c037b icedtea/build.sh
--- a/icedtea/build.sh	Wed Mar 21 13:36:40 2012 +0100
+++ b/icedtea/build.sh	Sun Apr 01 10:02:11 2012 +0200
@@ -112,10 +112,10 @@
 
 # Some additional VMs only build against one or the other version.
 if [ "${VERSIONSTR}" == "6" ]; then
- ICEDTEA_ADDITIONAL_VMS="cacao,jamvm,shark"
+ ICEDTEA_ADDITIONAL_VMS="cacao,jamvm,shark,zero"
  ADDITIONAL_OPTIONS=""
 elif [ "${VERSIONSTR}" == "7" ]; then
- ICEDTEA_ADDITIONAL_VMS="shark"
+ ICEDTEA_ADDITIONAL_VMS="cacao,jamvm"
  ADDITIONAL_OPTIONS="--disable-system-lcms --disable-system-gio"
 else
  ICEDTEA_ADDITIONAL_VMS=""


From bugzilla-daemon at icedtea.classpath.org  Sun Apr  1 14:19:30 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Sun, 01 Apr 2012 21:19:30 +0000
Subject: [Bug 912] New: Pentaho Kettle' spoon.sh  fatal error, SIGSEGV
Message-ID: <bug-912-30@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=912

             Bug #: 912
           Summary: Pentaho Kettle' spoon.sh  fatal error, SIGSEGV
    Classification: Unclassified
           Product: IcedTea
           Version: 6-1.10.4
          Platform: x86
        OS/Version: Linux
            Status: NEW
          Severity: blocker
          Priority: P3
         Component: IcedTea
        AssignedTo: unassigned at icedtea.classpath.org
        ReportedBy: jjantmba at yahoo.es


Hi,

Latest two releases of Pentaho Kettle (Community Edition) remain useless to me
because main tool - spoon.sh - crashes at start time.

Error message is:
...
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x8c82a0c9, pid=3841, tid=3065490288
#
# JRE version: 6.0_22-b22
# Java VM: OpenJDK Client VM (20.0-b11 mixed mode linux-x86 )
# Derivative: IcedTea6 1.10.4
# Distribution: Mageia 1, package fedora-24.b22.6.1.mga1-i386
# Problematic frame:
# C  [libxul.so+0x11190c9]  NS_InvokeByIndex_P+0x83f9
#
# An error report file with more information is saved as:
# /home/.../data-integration-4.2.1-stable/hs_err_pid3841.log
#
# If you would like to submit a bug report, please include
# instructions how to reproduce the bug and visit:
#   http://icedtea.classpath.org/bugzilla
#
...

Thank you.

-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


From aph at redhat.com  Mon Apr  2 06:08:29 2012
From: aph at redhat.com (Andrew Haley)
Date: Mon, 02 Apr 2012 14:08:29 +0100
Subject: ARM: JSR 292 MethodHandle support
Message-ID: <4F79A4CD.40408@redhat.com>

This is a patch against http://icedtea.classpath.org/hg/release/icedtea7-forest-2.1/hotspot

It adds support for the various MethodHandle::invoke methods,
MethodHandle constants, and the invokedynamic opcode.  The JIT mostly
falls back to the interpreter for support, but ldc MethodHandle is
handled in the case where it's already resolved.

Zero's support for MethodHandles is incomplete, so some tests will
still fail.  Once Zero is complete, we can revisit the JIT with a mind
to speeding-up invokedynamic.

I've asked Andrew Dinn to help review this patch.

Andrew.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pp
Url: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120402/a2dcb655/pp.ksh 

From adinn at redhat.com  Mon Apr  2 06:13:32 2012
From: adinn at redhat.com (Andrew Dinn)
Date: Mon, 02 Apr 2012 14:13:32 +0100
Subject: Newbie news . . .
Message-ID: <4F79A5FC.4010906@redhat.com>

Hi all,

Just posting a hello to notify that I am on the list :-).

I will be working with Andrew Haley on maintenance of the ARMv7 JIT he 
announced and demoed at FOSDEM.

regards,


Andrew Dinn
-----------


From jvanek at redhat.com  Mon Apr  2 06:14:08 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Mon, 02 Apr 2012 15:14:08 +0200
Subject: [RFC] Fix IndexOutOfBoundException because of corrupted entry
	in recently_used file
In-Reply-To: <1332938501.1397.15.camel@localhost.localdomain>
References: <1332938501.1397.15.camel@localhost.localdomain>
Message-ID: <4F79A620.2090702@redhat.com>

On 03/28/2012 02:41 PM, Thomas Meyer wrote:
> # HG changeset patch
> # User Thomas Meyer<thomas at m3y3r.de>
> # Date 1332937976 -7200
> # Node ID f6540088f06f2d9962e1c5b7858c4212f045759e
> # Parent  093896b370d3ed3f1fc3527084133b8e388bf0ae
> Fix IndexOutOfBoundException because of corrupt "recently_used" index file of cached files. Better solution would be to do this validation in CacheLRUWrapper.load()
>
> diff -r 093896b370d3 -r f6540088f06f netx/net/sourceforge/jnlp/cache/CacheUtil.java
> --- a/netx/net/sourceforge/jnlp/cache/CacheUtil.java	Wed Mar 28 12:08:10 2012 +0200
> +++ b/netx/net/sourceforge/jnlp/cache/CacheUtil.java	Wed Mar 28 14:32:56 2012 +0200
> @@ -354,17 +354,22 @@
>
>                   }
>               } while (entries == null);
> +
>               // Start searching from the most recent to least recent.
>               for (Entry<String, String>  e : entries) {
>                   final String key = e.getKey();
> -                final String path = e.getValue();
> +                String path = e.getValue();
>
>                   if (path != null) {
> -                    if (pathToURLPath(path).equals(urlPath.getPath())) { // Match found.
> -                        cacheFile = new File(path);
> -                        lruHandler.updateEntry(key);
> -                        break; // Stop searching since we got newest one already.
> -                    }
> +                    path=pathToURLPath(path);
> +                    if(path == null)
> +                        lruHandler.removeEntry(key);
> +                    else
> +                        if (path.equals(urlPath.getPath())) { // Match found.
> +                            cacheFile = new File(path);
> +                            lruHandler.updateEntry(key);
> +                            break; // Stop searching since we got newest one already.
> +                        }
>                   }
>               }
>               return cacheFile;
> @@ -377,6 +382,13 @@
>       private static String pathToURLPath(String path) {
>           int len = cacheDir.length();
>           int index = path.indexOf(File.separatorChar, len + 1);
> +
> +        /*
> +         * somehow the lru entries got corrupt. ignore this entry and
> +         * don't fail with an IndexOutOfBoundsException
> +         */
> +        if(index<  0)
> +            return null;
>           return path.substring(index);
>       }
>
>
>

Hi there! What are the prerequisites leading to do this  state?
I have fixed lru cache once already (for throwing NonIntegerValue exception) but I have never seen 
this error even when I was trying to corrupt cache, and I agree with you that this should be done in 
CacheLRUWrapper. Can you please provide (plaintext is enough) some reproducer?
If you will be willing to add this behaviou to 
icedtea-web/tests/jnlp_tests/signed/CacheReproducer/testcases/CacheReproducerTest.java it will be 
really great (You should do this according to commit policy O:) "IcedTea-Web code changes/new 
feature should be accompanied with appropriate tests (JUnit class and/or reproducer). If no tests 
are added/modified, changes should be accompanied with an explanation as to why. " O:)

 From cache record eg.:
1332779007444,35=/home/user/.icedtea/cache/35/http/localhost/SetContextClassLoader.jnlp

I see that this is removing "/home/user/.icedtea/cache/" correct?

So it can fail when:
  - recentlyused file have moved
  - javaws was killed during writeing

In both cases I would prefer cleaning of cache instead of neverending removing of entry.

So after "lruHandler.removeEntry(key);" should be save() at least to prevent this to happen again 
and again. But this brings other issues (like touching cache of other running javaws)

However, As best for fix this issue I'm considering change in CacheLRUWrapper's 
getLRUSortedEntries() to put to value already prepared path (or object with both prepared/full paths).
Then IndexOutOfBounds will be wrapped by LruCache exception and cache will be properly cleared.
However the cleanCache() method in CacheUtil will need small fixing after this too.

What do you think?


Thank you in advance, and Tyvm for getting the issue!
J.


From stefan at complang.tuwien.ac.at  Mon Apr  2 06:46:19 2012
From: stefan at complang.tuwien.ac.at (Stefan Ring)
Date: Mon, 2 Apr 2012 15:46:19 +0200
Subject: Newbie news . . .
In-Reply-To: <4F79A5FC.4010906@redhat.com>
References: <4F79A5FC.4010906@redhat.com>
Message-ID: <CAAxjCEy17xL6ZFr8oRqpbWz18iobio0=W_jFTxSH0zojbEV6aA@mail.gmail.com>

Yeah, we really need more Andrewses on this list ;).

Very welcome indeed, have fun!


From dbhole at redhat.com  Mon Apr  2 07:03:06 2012
From: dbhole at redhat.com (Deepak Bhole)
Date: Mon, 2 Apr 2012 10:03:06 -0400
Subject: Newbie news . . .
In-Reply-To: <4F79A5FC.4010906@redhat.com>
References: <4F79A5FC.4010906@redhat.com>
Message-ID: <20120402140303.GA32216@redhat.com>

* Andrew Dinn <adinn at redhat.com> [2012-04-02 09:14]:
> Hi all,
> 
> Just posting a hello to notify that I am on the list :-).
> 
> I will be working with Andrew Haley on maintenance of the ARMv7 JIT
> he announced and demoed at FOSDEM.
> 

Welcome to the group Andrew! :)

Cheers,
Deepak


From ddadacha at redhat.com  Mon Apr  2 08:06:48 2012
From: ddadacha at redhat.com (Danesh Dadachanji)
Date: Mon, 02 Apr 2012 11:06:48 -0400
Subject: [RFC][icedtea-web] Fix JarSigner to check that cert start dates
	have passed
In-Reply-To: <20120330212231.GO14039@redhat.com>
References: <4F7610BE.7070703@redhat.com> <20120330202049.GM14039@redhat.com>
	<4F761FE0.8090802@redhat.com> <20120330212231.GO14039@redhat.com>
Message-ID: <4F79C088.2040101@redhat.com>


On 30/03/12 05:22 PM, Deepak Bhole wrote:
> * Danesh Dadachanji<ddadacha at redhat.com>  [2012-03-30 17:04]:
>> On 30/03/12 04:20 PM, Deepak Bhole wrote:
>>> * Danesh Dadachanji<ddadacha at redhat.com>   [2012-03-30 16:02]:
>>>> Hi,
>>>>
>>>> Currently, JarSigner never sets notYetValidCert to true, the
>>>> notBefore date is never checked when sorting out the certificates.
>>>> If it were true, the certificate would be considered as having
>>>> signing issues and all the unverified prompts would start
>>>> triggering. Attached is a patch to fix this, everything else is
>>>> already taken care of WRT notYetValidCert being checked in other
>>>> places.
>>>>
>>>> ChangeLog
>>>> +2012-03-30  Danesh Dadachanji<ddadacha at redhat.com>
>>>> +
>>>> +	Certificate start dates are not being checked, they are still verified
>>>> +	even if the date has yet not been reached.
>>>> +	* netx/net/sourceforge/jnlp/tools/JarSigner.java (verifyJar): If the start
>>>> +	date is in the future, set notYetValidCert to true.
>>>> +
>>>>
>>>>
>>>> Okay for HEAD? Thoughts on backporting? I don't think this should
>>>> wait to be backported since currently it is verifying certificates
>>>> it should not be letting through, misleading users when dialogs
>>>> prompt.
>>>>
>>>
>>> I think this one is fine for 1.1 and 1.2 in addition to HEAD.
>>
>> Bah noticed a bug in the patch, if the cert expires in 6 months or
>> less, that flag is set and the notYetValidCert isn't. I tested it
>> with a 365 day valid cert the first time around. :S
>>
>
> This looks fine. Btw, do we really need a warning for something about to
> expire? Until it expires, the cert is completely valid. Perhaps we
> should remove it?

I don't see the warning being too troublesome if it's not directly shown 
to the user. It's only shown if you click on More Information. It also 
doesn't affect whether or not the cert is verified so I would guess most 
users don't even notice it if the signer is fine. =) Perhaps we should 
change the icon associated with it to be more friendly (currently the 
warning one with the yellow triangle and "!"). What do you think?

The only thing this flag really does is add "SRunWithoutRestrictions" to 
the warnings list (apart from the "SHasExpiringCert" warning). I'm not 
entirely sure it should be doing this though..

>> Updated patch in attachment, ChangeLog is the same. Thanks to
>> Omair's comment, I did a slightly more extensive search on where
>> notBefore() is called as well as my original search for
>> "notYetValidCert", everything looks logical now.
>>
>> I've now tested this with:
>>   - a cert that has notBefore=$YESTERDAY, notAfter=$TOMORROW: Both
>> "not yet valid" and "expiring in 6 months" warnings show in More
>> Info dialog.
>>   - a cert that has notBefore=$YESTERDAY, notAfter=$NEXT_YEAR: Just
>> "not yet valid" warning shows in More Info dialog.
>>
>> Is there anything else I should test? /me can't think of anything
>> off the bat.
>>
>> Cheers,
>> Danesh
>
>> diff --git a/netx/net/sourceforge/jnlp/tools/JarSigner.java b/netx/net/sourceforge/jnlp/tools/JarSigner.java
>> --- a/netx/net/sourceforge/jnlp/tools/JarSigner.java
>> +++ b/netx/net/sourceforge/jnlp/tools/JarSigner.java
>> @@ -297,9 +297,15 @@ public class JarSigner implements CertVe
>>                               if (cert instanceof X509Certificate) {
>>                                   checkCertUsage((X509Certificate) cert, null);
>>                                   if (!showcerts) {
>> +                                    long notBefore = ((X509Certificate) cert)
>> +                                                     .getNotBefore().getTime();
>>                                       long notAfter = ((X509Certificate) cert)
>>                                                       .getNotAfter().getTime();
>>
>> +                                    if (now<  notBefore) {
>> +                                        notYetValidCert = true;
>> +                                    }
>> +
>>                                       if (notAfter<  now) {
>>                                           hasExpiredCert = true;
>>                                       } else if (notAfter<  now + SIX_MONTHS) {
>


From dbhole at redhat.com  Mon Apr  2 08:11:07 2012
From: dbhole at redhat.com (Deepak Bhole)
Date: Mon, 2 Apr 2012 11:11:07 -0400
Subject: [RFC][icedtea-web] Fix JarSigner to check that cert start dates
	have passed
In-Reply-To: <4F79C088.2040101@redhat.com>
References: <4F7610BE.7070703@redhat.com> <20120330202049.GM14039@redhat.com>
	<4F761FE0.8090802@redhat.com> <20120330212231.GO14039@redhat.com>
	<4F79C088.2040101@redhat.com>
Message-ID: <20120402151106.GD32216@redhat.com>

* Danesh Dadachanji <ddadacha at redhat.com> [2012-04-02 11:06]:
> 
> On 30/03/12 05:22 PM, Deepak Bhole wrote:
> >* Danesh Dadachanji<ddadacha at redhat.com>  [2012-03-30 17:04]:
> >>On 30/03/12 04:20 PM, Deepak Bhole wrote:
> >>>* Danesh Dadachanji<ddadacha at redhat.com>   [2012-03-30 16:02]:
> >>>>Hi,
> >>>>
> >>>>Currently, JarSigner never sets notYetValidCert to true, the
> >>>>notBefore date is never checked when sorting out the certificates.
> >>>>If it were true, the certificate would be considered as having
> >>>>signing issues and all the unverified prompts would start
> >>>>triggering. Attached is a patch to fix this, everything else is
> >>>>already taken care of WRT notYetValidCert being checked in other
> >>>>places.
> >>>>
> >>>>ChangeLog
> >>>>+2012-03-30  Danesh Dadachanji<ddadacha at redhat.com>
> >>>>+
> >>>>+	Certificate start dates are not being checked, they are still verified
> >>>>+	even if the date has yet not been reached.
> >>>>+	* netx/net/sourceforge/jnlp/tools/JarSigner.java (verifyJar): If the start
> >>>>+	date is in the future, set notYetValidCert to true.
> >>>>+
> >>>>
> >>>>
> >>>>Okay for HEAD? Thoughts on backporting? I don't think this should
> >>>>wait to be backported since currently it is verifying certificates
> >>>>it should not be letting through, misleading users when dialogs
> >>>>prompt.
> >>>>
> >>>
> >>>I think this one is fine for 1.1 and 1.2 in addition to HEAD.
> >>
> >>Bah noticed a bug in the patch, if the cert expires in 6 months or
> >>less, that flag is set and the notYetValidCert isn't. I tested it
> >>with a 365 day valid cert the first time around. :S
> >>
> >
> >This looks fine. Btw, do we really need a warning for something about to
> >expire? Until it expires, the cert is completely valid. Perhaps we
> >should remove it?
> 
> I don't see the warning being too troublesome if it's not directly
> shown to the user. It's only shown if you click on More Information.
> It also doesn't affect whether or not the cert is verified so I
> would guess most users don't even notice it if the signer is fine.
> =) Perhaps we should change the icon associated with it to be more
> friendly (currently the warning one with the yellow triangle and
> "!"). What do you think?
>

+1 for changing icon then, but that would be a separate patch.

This one is OK for 1.1, 1.2 and HEAD.

Cheers,
Deepak
 


From ddadacha at icedtea.classpath.org  Mon Apr  2 08:23:52 2012
From: ddadacha at icedtea.classpath.org (ddadacha at icedtea.classpath.org)
Date: Mon, 02 Apr 2012 15:23:52 +0000
Subject: /hg/icedtea-web: Fixed check for a certificate whose start date ...
Message-ID: <hg.eb3a40549623.1333380232.8643924302249223276@icedtea.classpath.org>

changeset eb3a40549623 in /hg/icedtea-web
details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=eb3a40549623
author: Danesh Dadachanji <ddadacha at redhat.com>
date: Mon Apr 02 11:23:18 2012 -0400

	Fixed check for a certificate whose start date has not yet been reached.


diffstat:

 ChangeLog                                      |  7 +++++++
 netx/net/sourceforge/jnlp/tools/JarSigner.java |  6 ++++++
 2 files changed, 13 insertions(+), 0 deletions(-)

diffs (33 lines):

diff -r 14284e2041de -r eb3a40549623 ChangeLog
--- a/ChangeLog	Thu Mar 22 13:12:44 2012 -0400
+++ b/ChangeLog	Mon Apr 02 11:23:18 2012 -0400
@@ -1,3 +1,10 @@
+2012-03-30  Danesh Dadachanji  <ddadacha at redhat.com>
+
+	Certificate start dates are not being checked, they are still verified
+	even if the date has yet not been reached.
+	* netx/net/sourceforge/jnlp/tools/JarSigner.java (verifyJar): If the start
+	date is in the future, set notYetValidCert to true.
+
 2012-03-21  Omair Majid  <omajid at redhat.com>
 
 	* tests/netx/unit/net/sourceforge/jnlp/JNLPMatcherTest.java
diff -r 14284e2041de -r eb3a40549623 netx/net/sourceforge/jnlp/tools/JarSigner.java
--- a/netx/net/sourceforge/jnlp/tools/JarSigner.java	Thu Mar 22 13:12:44 2012 -0400
+++ b/netx/net/sourceforge/jnlp/tools/JarSigner.java	Mon Apr 02 11:23:18 2012 -0400
@@ -297,9 +297,15 @@
                             if (cert instanceof X509Certificate) {
                                 checkCertUsage((X509Certificate) cert, null);
                                 if (!showcerts) {
+                                    long notBefore = ((X509Certificate) cert)
+                                                     .getNotBefore().getTime();
                                     long notAfter = ((X509Certificate) cert)
                                                     .getNotAfter().getTime();
 
+                                    if (now < notBefore) {
+                                        notYetValidCert = true;
+                                    }
+
                                     if (notAfter < now) {
                                         hasExpiredCert = true;
                                     } else if (notAfter < now + SIX_MONTHS) {


From ddadacha at icedtea.classpath.org  Mon Apr  2 08:27:10 2012
From: ddadacha at icedtea.classpath.org (ddadacha at icedtea.classpath.org)
Date: Mon, 02 Apr 2012 15:27:10 +0000
Subject: /hg/release/icedtea-web-1.2: Fixed check for a certificate whose...
Message-ID: <hg.9c0e0aec8ac8.1333380430.-5934593987637005768@icedtea.classpath.org>

changeset 9c0e0aec8ac8 in /hg/release/icedtea-web-1.2
details: http://icedtea.classpath.org/hg/release/icedtea-web-1.2?cmd=changeset;node=9c0e0aec8ac8
author: Danesh Dadachanji <ddadacha at redhat.com>
date: Mon Apr 02 11:26:17 2012 -0400

	Fixed check for a certificate whose start date has not yet been reached.


diffstat:

 ChangeLog                                      |  7 +++++++
 netx/net/sourceforge/jnlp/tools/JarSigner.java |  6 ++++++
 2 files changed, 13 insertions(+), 0 deletions(-)

diffs (33 lines):

diff -r 9b8837c53c09 -r 9c0e0aec8ac8 ChangeLog
--- a/ChangeLog	Wed Mar 14 15:05:54 2012 -0400
+++ b/ChangeLog	Mon Apr 02 11:26:17 2012 -0400
@@ -1,3 +1,10 @@
+2012-03-30  Danesh Dadachanji  <ddadacha at redhat.com>
+
+	Certificate start dates are not being checked, they are still verified
+	even if the date has yet not been reached.
+	* netx/net/sourceforge/jnlp/tools/JarSigner.java (verifyJar): If the start
+	date is in the future, set notYetValidCert to true.
+
 2012-03-14  Deepak Bhole <dbhole at redhat.com>
 			Omair Majid <omajid at redhat.com>
 
diff -r 9b8837c53c09 -r 9c0e0aec8ac8 netx/net/sourceforge/jnlp/tools/JarSigner.java
--- a/netx/net/sourceforge/jnlp/tools/JarSigner.java	Wed Mar 14 15:05:54 2012 -0400
+++ b/netx/net/sourceforge/jnlp/tools/JarSigner.java	Mon Apr 02 11:26:17 2012 -0400
@@ -297,9 +297,15 @@
                             if (cert instanceof X509Certificate) {
                                 checkCertUsage((X509Certificate) cert, null);
                                 if (!showcerts) {
+                                    long notBefore = ((X509Certificate) cert)
+                                                     .getNotBefore().getTime();
                                     long notAfter = ((X509Certificate) cert)
                                                     .getNotAfter().getTime();
 
+                                    if (now < notBefore) {
+                                        notYetValidCert = true;
+                                    }
+
                                     if (notAfter < now) {
                                         hasExpiredCert = true;
                                     } else if (notAfter < now + SIX_MONTHS) {


From ddadacha at icedtea.classpath.org  Mon Apr  2 08:29:34 2012
From: ddadacha at icedtea.classpath.org (ddadacha at icedtea.classpath.org)
Date: Mon, 02 Apr 2012 15:29:34 +0000
Subject: /hg/release/icedtea-web-1.1: Fixed check for a certificate whose...
Message-ID: <hg.4672053d61e0.1333380574.-5934593987637005765@icedtea.classpath.org>

changeset 4672053d61e0 in /hg/release/icedtea-web-1.1
details: http://icedtea.classpath.org/hg/release/icedtea-web-1.1?cmd=changeset;node=4672053d61e0
author: Danesh Dadachanji <ddadacha at redhat.com>
date: Mon Apr 02 11:28:21 2012 -0400

	Fixed check for a certificate whose start date has not yet been reached.


diffstat:

 ChangeLog                                      |  7 +++++++
 netx/net/sourceforge/jnlp/tools/JarSigner.java |  6 ++++++
 2 files changed, 13 insertions(+), 0 deletions(-)

diffs (33 lines):

diff -r d4a6d82ed0ae -r 4672053d61e0 ChangeLog
--- a/ChangeLog	Wed Mar 14 15:05:54 2012 -0400
+++ b/ChangeLog	Mon Apr 02 11:28:21 2012 -0400
@@ -1,3 +1,10 @@
+2012-03-30  Danesh Dadachanji  <ddadacha at redhat.com>
+
+	Certificate start dates are not being checked, they are still verified
+	even if the date has yet not been reached.
+	* netx/net/sourceforge/jnlp/tools/JarSigner.java (verifyJar): If the start
+	date is in the future, set notYetValidCert to true.
+
 2012-03-05  Deepak Bhole <dbhole at redhat.com>
 
 	* configure.ac: Prepare for 1.1.6
diff -r d4a6d82ed0ae -r 4672053d61e0 netx/net/sourceforge/jnlp/tools/JarSigner.java
--- a/netx/net/sourceforge/jnlp/tools/JarSigner.java	Wed Mar 14 15:05:54 2012 -0400
+++ b/netx/net/sourceforge/jnlp/tools/JarSigner.java	Mon Apr 02 11:28:21 2012 -0400
@@ -297,9 +297,15 @@
                             if (cert instanceof X509Certificate) {
                                 checkCertUsage((X509Certificate) cert, null);
                                 if (!showcerts) {
+                                    long notBefore = ((X509Certificate) cert)
+                                                     .getNotBefore().getTime();
                                     long notAfter = ((X509Certificate) cert)
                                                     .getNotAfter().getTime();
 
+                                    if (now < notBefore) {
+                                        notYetValidCert = true;
+                                    }
+
                                     if (notAfter < now) {
                                         hasExpiredCert = true;
                                     } else if (notAfter < now + SIX_MONTHS) {


From ddadacha at redhat.com  Mon Apr  2 08:32:30 2012
From: ddadacha at redhat.com (Danesh Dadachanji)
Date: Mon, 02 Apr 2012 11:32:30 -0400
Subject: [RFC][icedtea-web] Fix JarSigner to check that cert start dates
	have passed
In-Reply-To: <20120402151106.GD32216@redhat.com>
References: <4F7610BE.7070703@redhat.com> <20120330202049.GM14039@redhat.com>
	<4F761FE0.8090802@redhat.com> <20120330212231.GO14039@redhat.com>
	<4F79C088.2040101@redhat.com> <20120402151106.GD32216@redhat.com>
Message-ID: <4F79C68E.2000100@redhat.com>



On 02/04/12 11:11 AM, Deepak Bhole wrote:
> * Danesh Dadachanji<ddadacha at redhat.com>  [2012-04-02 11:06]:
>>
>> On 30/03/12 05:22 PM, Deepak Bhole wrote:
>>> * Danesh Dadachanji<ddadacha at redhat.com>   [2012-03-30 17:04]:
>>>> On 30/03/12 04:20 PM, Deepak Bhole wrote:
>>>>> * Danesh Dadachanji<ddadacha at redhat.com>    [2012-03-30 16:02]:
>>>>>> Hi,
>>>>>>
>>>>>> Currently, JarSigner never sets notYetValidCert to true, the
>>>>>> notBefore date is never checked when sorting out the certificates.
>>>>>> If it were true, the certificate would be considered as having
>>>>>> signing issues and all the unverified prompts would start
>>>>>> triggering. Attached is a patch to fix this, everything else is
>>>>>> already taken care of WRT notYetValidCert being checked in other
>>>>>> places.
>>>>>>
>>>>>> ChangeLog
>>>>>> +2012-03-30  Danesh Dadachanji<ddadacha at redhat.com>
>>>>>> +
>>>>>> +	Certificate start dates are not being checked, they are still verified
>>>>>> +	even if the date has yet not been reached.
>>>>>> +	* netx/net/sourceforge/jnlp/tools/JarSigner.java (verifyJar): If the start
>>>>>> +	date is in the future, set notYetValidCert to true.
>>>>>> +
>>>>>>
>>>>>>
>>>>>> Okay for HEAD? Thoughts on backporting? I don't think this should
>>>>>> wait to be backported since currently it is verifying certificates
>>>>>> it should not be letting through, misleading users when dialogs
>>>>>> prompt.
>>>>>>
>>>>>
>>>>> I think this one is fine for 1.1 and 1.2 in addition to HEAD.
>>>>
>>>> Bah noticed a bug in the patch, if the cert expires in 6 months or
>>>> less, that flag is set and the notYetValidCert isn't. I tested it
>>>> with a 365 day valid cert the first time around. :S
>>>>
>>>
>>> This looks fine. Btw, do we really need a warning for something about to
>>> expire? Until it expires, the cert is completely valid. Perhaps we
>>> should remove it?
>>
>> I don't see the warning being too troublesome if it's not directly
>> shown to the user. It's only shown if you click on More Information.
>> It also doesn't affect whether or not the cert is verified so I
>> would guess most users don't even notice it if the signer is fine.
>> =) Perhaps we should change the icon associated with it to be more
>> friendly (currently the warning one with the yellow triangle and
>> "!"). What do you think?
>>
>
> +1 for changing icon then, but that would be a separate patch.
>

Alright, I'll take a look at the other ones we have and implement this 
after the other changes to JarSigner are made.

> This one is OK for 1.1, 1.2 and HEAD.
>

Thanks! Pushed here:

http://icedtea.classpath.org/hg/icedtea-web/rev/eb3a40549623
http://icedtea.classpath.org/hg/release/icedtea-web-1.2/rev/9c0e0aec8ac8
http://icedtea.classpath.org/hg/release/icedtea-web-1.1/rev/4672053d61e0

Cheers,
Danesh


From bugzilla-daemon at icedtea.classpath.org  Mon Apr  2 08:39:07 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Mon, 02 Apr 2012 15:39:07 +0000
Subject: [Bug 912] Pentaho Kettle' spoon.sh  fatal error, SIGSEGV
In-Reply-To: <bug-912-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-912-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-912-30-H0rEi0LAbv@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=912

Deepak Bhole <dbhole at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dbhole at redhat.com

--- Comment #1 from Deepak Bhole <dbhole at redhat.com> 2012-04-02 15:39:07 UTC ---
Can you please also attach
/home/.../data-integration-4.2.1-stable/hs_err_pid3841.log after redacting
anything sensitive? 

A full stack trace (if available) would be great too!

-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


From omajid at redhat.com  Mon Apr  2 11:02:46 2012
From: omajid at redhat.com (Omair Majid)
Date: Mon, 02 Apr 2012 14:02:46 -0400
Subject: [icedtea-web] RFC: Fix pac tests
In-Reply-To: <4F71DBE0.6040105@redhat.com>
References: <4F6D7437.8010804@redhat.com> <4F70A806.8060108@redhat.com>
	<4F70ADA7.2060707@redhat.com> <4F716946.5060900@redhat.com>
	<4F71DBE0.6040105@redhat.com>
Message-ID: <4F79E9C6.1030306@redhat.com>

On 03/27/2012 11:25 AM, Omair Majid wrote:
> On 03/27/2012 03:16 AM, Jiri Vanek wrote:
>> Among the wrapping and other fixing you did are several times just
>> fixes of indentation. Do you mind to push those fixes separately and
>> repost the fixes you did again?
> 
> Ah. Sorry for that. How does the new patch look? The file uses a really
> strange mix of tabs and spaces (both 4 and 2) for indentation, making it
> really hard to write code that fits in with the existing indentation. I
> hope I have the changes right this time.
> 

Ping?

Thanks,
Omair


From dbhole at redhat.com  Mon Apr  2 13:25:13 2012
From: dbhole at redhat.com (Deepak Bhole)
Date: Mon, 2 Apr 2012 16:25:13 -0400
Subject: [rfc][icedtea-web] virtual server thread marked as daemon by
	default
In-Reply-To: <4F6B1827.9060207@redhat.com>
References: <4F6B1827.9060207@redhat.com>
Message-ID: <20120402202512.GD5567@redhat.com>

* Jiri Vanek <jvanek at redhat.com> [2012-03-22 08:16]:
> although junit was handling "redundant" threads pretty well, I think it is correct thing to do
> 
> Any reason why not?	
> 
> 2012-03-22  Jiri Vanek <jvanek at redhat.com>
> 
> 	test's virtual server thread marked as daemon by default

"test's" -> "Tests"

After that, OK for 1.2 (if applicable) and HEAD.

Cheers,
Deepak

> 	* tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java:
> 	All (ServerLauncher) instances returned by methods were marked as daemon
> 	by default. Possibility to change and api were kept.

> diff -r 89609d0a4e1c tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java
> --- a/tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java	Mon Mar 19 14:37:03 2012 -0400
> +++ b/tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java	Thu Mar 22 12:20:47 2012 +0100
> @@ -186,9 +186,12 @@
>       * usefull for testing application loading from different url then base
>       */
>      public static ServerLauncher getIndependentInstance() {
> +        return getIndependentInstance(true);
> +    }
> +    public static ServerLauncher getIndependentInstance(boolean daemon) {
>          String dir = (System.getProperty(TEST_SERVER_DIR));
>          try{
> -            return getIndependentInstance(dir, findFreePort());
> +            return getIndependentInstance(dir, findFreePort(),daemon);
>          }catch (Exception ex){
>              throw  new RuntimeException(ex);
>          }
> @@ -200,9 +203,13 @@
>       * @return new not cached iserver instance on random port,
>       * usefull for testing application loading from different url then base
>       */
> +    
>      public static ServerLauncher getIndependentInstance(int port) {
> +        return getIndependentInstance(port, true);
> +    }
> +    public static ServerLauncher getIndependentInstance(int port,boolean daemon) {
>          String dir = (System.getProperty(TEST_SERVER_DIR));
> -        return getIndependentInstance(dir,port);
> +        return getIndependentInstance(dir,port,daemon);
>      }
>  
>      /**
> @@ -210,7 +217,11 @@
>       * @return new not cached iserver instance on random port upon custom www root directory,
>       * usefull for testing application loading from different url then base
>       */
> +
>      public static ServerLauncher getIndependentInstance(String dir, int port) {
> +        return getIndependentInstance(dir, port, true);
> +    }
> +    public static ServerLauncher getIndependentInstance(String dir, int port,boolean daemon) {
>  
>  
>          if (dir == null || dir.trim().length() == 0 || !new File(dir).exists() || !new File(dir).isDirectory()) {
> @@ -218,7 +229,9 @@
>          }
>          try {
>              ServerLauncher lServerLuncher = new ServerLauncher(port, new File(dir));
> -            new Thread(lServerLuncher).start();
> +            Thread r=new Thread(lServerLuncher);
> +            r.setDaemon(daemon);
> +            r.start();
>              return lServerLuncher;
>          } catch (Exception ex) {
>              throw new RuntimeException(ex);



From ddadacha at redhat.com  Mon Apr  2 13:46:47 2012
From: ddadacha at redhat.com (Danesh Dadachanji)
Date: Mon, 02 Apr 2012 16:46:47 -0400
Subject: [RFC][icedtea-web] Unit tests for the new updates to JarSIgner
	(incomplete)
Message-ID: <4F7A1037.7060405@redhat.com>

Hi,

I've been working on updating JarSigner to be able to handle multiple 
signers properly. Currently, it mashes and saves all of the signers' 
properties (flags for expired/badly signed/not yet valid) as one. In 
other words, if one signer has expired, all signers are seen by 
IcedTea-Web as expired. If one has signing issues, then they all have 
signing issues. This is definitely not an ideal solution since we're 
telling users that verifiable applications are not verified.

The attached patch contains a set of unit tests for the (former) 
verifyJar method. I'm going to avoid including the actual code for these 
changes just yet because the entire class isn't fully cleaned up. Here's 
a bit of background info on what I've changed though.


* What verifyJar should be doing:

My understanding of the idea behind verifyJar is that it does 2 somewhat 
separate tasks. First, given a jar, iterate over all of its entries. For 
every entry that can be signed, go through the list of signers and see 
if any have issues. If they do, setup the flags accordingly (issues 
could be expiry/bad key usage/not yet valid start date etc). Also, keep 
track of the number of entries each signer has signed, as well as the 
total number of possible signable entries. The second step is going 
through all of the signers after all the entries have been iterated over 
to see if there is a common signer that has signed them all. If there is 
any entry that is not signed but should be, or if there is one entry 
that does not share a common signer between all other entries, then this 
jar is considered UNSIGNED. If all entries (that should be signed) share 
a common signer, then the signer itself is checked. If the signer has 
signing issues, the jar is considered SIGNED_NOT_OKAY, if it has no 
signing issues, the jar is considered SIGNED_OK.

Please correct me if I am wrong!


* Summary of my changes to verifyJar:

I've split verifyJar into 2 methods, all the logic/implementations from 
line 265[1] and onwards is now in a method named verifyJarEntryCerts. 
Here's a quick snippet of its javadoc and method declaration:

     /**
      * Checks through all the jar entries for signers, storing all the 
common
      * ones in the certs hash map.
      * @param jarHasManifest Whether or not the associated jar has a 
manifest.
      * @param entries The list of entries in the associated jar.
      * @return If there is at least one signable entry that is not 
signed by a
      * common signer, return UNSIGNED. Otherwise every signable entry is
      * signed by at least one common signer. If the signer has no issues,
      * return SIGNED_OK. If there are any signing issues, return 
SIGNED_NOT_OK.
      * @throws Exception Will be thrown if there are issues with entries.
      */
     VerifyResult verifyJarEntryCerts(boolean jarHasManifest, 
Vector<JarEntry> entries) throws Exception

The reason I've split this method up is so that JarSigner can be made 
unit testable. The method verifyJar takes in a jar name and 
creating/commiting one to upstream isn't suitable. Instead, I've created 
an extra helper method that takes in a list of jar entries and tests 
everything the original code tests. The new unit test class then hard 
codes these entries, along with their signers, to make this method testable.

In order to do this, I've created a subclass of JarEntry so that I can 
skip all the unnecessary bits JarEntry does that is not needed by 
verifyJarEntryCerts.

For the entries' signers, I've created a helper class that creates 
X509Certificate objects with specified domain names/start dates/validity 
periods. This code is essentially taken from 
sun.security.tools.KeyTool#doGenKeyPair (which calls 
KeyTool#doSelfCert), I've removed the bits that aren't needed 
(KeyStore/alias etc) and left the bare minimum that is needed to create 
an X509Certificate. I'm not 100% sure of the copyright header that is 
needed for this class so I used the same one provided by KeyTool from 
here [2] (with s/2011/2012). I would appreciate any insight as to if 
this is correct. =)

The unit tests themselves are pretty self-explanatory, to save on 
space/repetition, I've kept testing 1 entry and then 3 entries with the 
same scenario under one method (with different asserts). I think this is 
cleanest but am open to criticism! I've covered everything I could think 
of except for the badKeyUsage/badExtendedKeyUsage/badNetscapeCertType 
cases, I have yet to figure out how to setup certs using them. Is there 
any corner case I've missed?

Comments are very appreciated!

Regards,
Danesh

[1] 
http://icedtea.classpath.org/hg/icedtea-web/file/tip/netx/net/sourceforge/jnlp/tools/JarSigner.java#l265
[2] 
http://icedtea.classpath.org/hg/icedtea8-forest/jdk/file/9a59860aaccb/src/share/classes/sun/security/tools/KeyTool.java
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jar-signer-tests-01.patch
Type: text/x-patch
Size: 23245 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120402/9adf2f45/jar-signer-tests-01.patch 

From ahughes at redhat.com  Mon Apr  2 15:50:30 2012
From: ahughes at redhat.com (Andrew Hughes)
Date: Mon, 02 Apr 2012 18:50:30 -0400 (EDT)
Subject: Configure changes for old build.sh autobuilder
In-Reply-To: <20120401080544.GA7342@toonder.wildebeest.org>
Message-ID: <763bc37a-609d-413c-9a6f-68d07edcc832@zmail17.collab.prod.int.phx2.redhat.com>

----- Original Message -----
> Hi,
> 
> Since zero and shark are both currently broken on 7 and have been for
> some
> time, I have disabled them on the old build.sh builder for now.
> 
> icedtea6 now has cacao,jamvm,shark,zero enabled.
> icedtea7 now has cacao,jamvm enabled.
> icedtea-trunk has no additional runtimes enabled.
> 

Would you be open to adding a different build, at least for Zero?
It could be run against the 2.1 branch.

I'd much prefer the main builds were just plain builds without
additional VMs enabled, as with icedtea-trunk.

> Cheers,
> 
> Mark
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From bugzilla-daemon at icedtea.classpath.org  Mon Apr  2 17:05:31 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Tue, 03 Apr 2012 00:05:31 +0000
Subject: [Bug 913] New: NSS PKCS11 provider fails to handle digest cloning
Message-ID: <bug-913-30@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=913

             Bug #: 913
           Summary: NSS PKCS11 provider fails to handle digest cloning
    Classification: Unclassified
           Product: IcedTea
           Version: 2.1.0
          Platform: x86_64
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: IcedTea
        AssignedTo: unassigned at icedtea.classpath.org
        ReportedBy: ahughes at redhat.com


Testing provider: SunPKCS11-NSS version 1.7
Unexpected Exception: MD5
java.lang.CloneNotSupportedException
        at java.security.MessageDigest$Delegate.clone(MessageDigest.java:555)
        at TestDigest.doTest(TestDigest.java:93)
        at UcryptoTest.main(UcryptoTest.java:60)
        at TestDigest.main(TestDigest.java:47)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:601)
        at
com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
        at java.lang.Thread.run(Thread.java:722)

See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6414899
There is a workaround involving nss.cfg that we should adopt for now.

-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


From bugzilla-daemon at icedtea.classpath.org  Mon Apr  2 17:06:32 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Tue, 03 Apr 2012 00:06:32 +0000
Subject: [Bug 913] NSS PKCS11 provider fails to handle digest cloning
In-Reply-To: <bug-913-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-913-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-913-30-CCMp1diYdd@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=913

Andrew John Hughes <ahughes at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
             Blocks|                            |901

--- Comment #1 from Andrew John Hughes <ahughes at redhat.com> 2012-04-03 00:06:32 UTC ---
Add metabug as blocker.

-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


From bugzilla-daemon at icedtea.classpath.org  Mon Apr  2 17:06:32 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Tue, 03 Apr 2012 00:06:32 +0000
Subject: [Bug 901] [METABUG] Give top priority to the PKCS11 NSS provider,
	due to performance advantages
In-Reply-To: <bug-901-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-901-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-901-30-UiOxXcC1Gz@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=901

Andrew John Hughes <ahughes at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |913

-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


From bugzilla-daemon at icedtea.classpath.org  Mon Apr  2 17:06:51 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Tue, 03 Apr 2012 00:06:51 +0000
Subject: [Bug 913] NSS PKCS11 provider fails to handle digest cloning
In-Reply-To: <bug-913-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-913-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-913-30-KTTPaQjN2o@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=913

Andrew John Hughes <ahughes at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at icedtea.classpat |ahughes at redhat.com
                   |h.org                       |

--- Comment #2 from Andrew John Hughes <ahughes at redhat.com> 2012-04-03 00:06:51 UTC ---
Assigning to me.

-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


From bugzilla-daemon at icedtea.classpath.org  Mon Apr  2 17:09:06 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Tue, 03 Apr 2012 00:09:06 +0000
Subject: [Bug 914] New: NSS PKCS11 provider fails to handle multipart AES
	encryption
Message-ID: <bug-914-30@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=914

             Bug #: 914
           Summary: NSS PKCS11 provider fails to handle multipart AES
                    encryption
    Classification: Unclassified
           Product: IcedTea
           Version: 2.1.0
          Platform: x86_64
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: IcedTea
        AssignedTo: unassigned at icedtea.classpath.org
        ReportedBy: ahughes at redhat.com


Input offset size: 1
Unexpected Exception: AES/ECB/NoPadding
java.security.ProviderException: update() failed
        at sun.security.pkcs11.P11Cipher.implUpdate(P11Cipher.java:599)
        at sun.security.pkcs11.P11Cipher.engineUpdate(P11Cipher.java:496)
        at javax.crypto.Cipher.update(Cipher.java:1701)
        at TestAES.testCipherOffset(TestAES.java:158)
        at TestAES.doTest(TestAES.java:66)
        at UcryptoTest.main(UcryptoTest.java:60)
        at TestAES.main(TestAES.java:55)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:601)
        at
com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
        at java.lang.Thread.run(Thread.java:722)
Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_DATA_LEN_RANGE
        at sun.security.pkcs11.wrapper.PKCS11.C_EncryptUpdate(Native Method)
        at sun.security.pkcs11.P11Cipher.implUpdate(P11Cipher.java:551)
        ... 12 more
Unexpected Exception: AES/CBC/NoPadding
java.security.InvalidKeyException: Could not initialize cipher
        at sun.security.pkcs11.P11Cipher.implInit(P11Cipher.java:384)
        at sun.security.pkcs11.P11Cipher.engineInit(P11Cipher.java:328)
        at javax.crypto.Cipher.init(Cipher.java:1312)
        at TestAES.testCipherOffset(TestAES.java:154)
        at TestAES.doTest(TestAES.java:66)
        at UcryptoTest.main(UcryptoTest.java:60)
        at TestAES.main(TestAES.java:55)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:601)
        at
com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
        at java.lang.Thread.run(Thread.java:722)
Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_DATA_LEN_RANGE
        at sun.security.pkcs11.wrapper.PKCS11.C_EncryptUpdate(Native Method)
        at sun.security.pkcs11.P11Cipher.implUpdate(P11Cipher.java:551)
        ... 12 more

Data is believed to not be padded.

-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


From bugzilla-daemon at icedtea.classpath.org  Mon Apr  2 17:09:30 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Tue, 03 Apr 2012 00:09:30 +0000
Subject: [Bug 914] NSS PKCS11 provider fails to handle multipart AES encryption
In-Reply-To: <bug-914-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-914-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-914-30-xyshPXh9Wt@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=914

Andrew John Hughes <ahughes at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |901
   Target Milestone|---                         |2.2

-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


From bugzilla-daemon at icedtea.classpath.org  Mon Apr  2 17:09:30 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Tue, 03 Apr 2012 00:09:30 +0000
Subject: [Bug 901] [METABUG] Give top priority to the PKCS11 NSS provider,
	due to performance advantages
In-Reply-To: <bug-901-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-901-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-901-30-lYUMvp3ILj@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=901

Andrew John Hughes <ahughes at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |914

-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


From bugzilla-daemon at icedtea.classpath.org  Mon Apr  2 17:09:55 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Tue, 03 Apr 2012 00:09:55 +0000
Subject: [Bug 914] NSS PKCS11 provider fails to handle multipart AES encryption
In-Reply-To: <bug-914-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-914-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-914-30-NnGG8PsEc6@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=914

Andrew John Hughes <ahughes at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at icedtea.classpat |ahughes at redhat.com
                   |h.org                       |

--- Comment #1 from Andrew John Hughes <ahughes at redhat.com> 2012-04-03 00:09:55 UTC ---
Assigning to me.

-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


From andrew at icedtea.classpath.org  Mon Apr  2 17:16:20 2012
From: andrew at icedtea.classpath.org (andrew at icedtea.classpath.org)
Date: Tue, 03 Apr 2012 00:16:20 +0000
Subject: /hg/release/icedtea7-2.1: Bump JDK & HotSpot changes to bring in...
Message-ID: <hg.8ea793eccbd1.1333412180.5789328834432805217@icedtea.classpath.org>

changeset 8ea793eccbd1 in /hg/release/icedtea7-2.1
details: http://icedtea.classpath.org/hg/release/icedtea7-2.1?cmd=changeset;node=8ea793eccbd1
author: Andrew John Hughes <ahughes at redhat.com>
date: Tue Apr 03 01:16:08 2012 +0100

	Bump JDK & HotSpot changes to bring in ARM port.

	2012-03-29  Andrew John Hughes  <ahughes at redhat.com>

	         * Makefile.am:
	         (HOTSPOT_CHANGESET): Sync to HEAD.
	         (JDK_CHANGESET): Likewise.
	         (HOTSPOT_SHA256SUM): Likewise.
	         (JDK_SHA256SUM): Likewise.


diffstat:

 ChangeLog   |  8 ++++++++
 Makefile.am |  8 ++++----
 2 files changed, 12 insertions(+), 4 deletions(-)

diffs (41 lines):

diff -r bb37d6d982f3 -r 8ea793eccbd1 ChangeLog
--- a/ChangeLog	Mon Feb 27 11:43:26 2012 -0500
+++ b/ChangeLog	Tue Apr 03 01:16:08 2012 +0100
@@ -1,3 +1,11 @@
+2012-03-29  Andrew John Hughes  <ahughes at redhat.com>
+
+         * Makefile.am:
+         (HOTSPOT_CHANGESET): Sync to HEAD.
+         (JDK_CHANGESET): Likewise.
+         (HOTSPOT_SHA256SUM): Likewise.
+         (JDK_SHA256SUM): Likewise.
+
 2012-02-24  Deepak Bhole <dbhole at redhat.com>
 
 	PR885: IcedTea7 does not build scripting support
diff -r bb37d6d982f3 -r 8ea793eccbd1 Makefile.am
--- a/Makefile.am	Mon Feb 27 11:43:26 2012 -0500
+++ b/Makefile.am	Tue Apr 03 01:16:08 2012 +0100
@@ -5,18 +5,18 @@
 COMBINED_VERSION = $(JDK_UPDATE_VERSION)-$(OPENJDK_VERSION)
 
 CORBA_CHANGESET = 5617f6c5cc94
-HOTSPOT_CHANGESET = 0e651e004747
+HOTSPOT_CHANGESET = 30c4dc24823a
 JAXP_CHANGESET = 1cf75c0e2c96
 JAXWS_CHANGESET = 7edfbfe974f2
-JDK_CHANGESET = 50f6f276a06c
+JDK_CHANGESET = 2d8ad70a2243
 LANGTOOLS_CHANGESET = b534c4c6cd9b
 OPENJDK_CHANGESET = 22cc03983e20
 
 CORBA_SHA256SUM = 963915483530f311ff313635f79ed11ea7ce5a1c0dbee5d1acb1994132857fa3
-HOTSPOT_SHA256SUM = d68455e5cdb14280cd61155a4e9d531e90b073607f4367e93ead0fcf34476ae1
+HOTSPOT_SHA256SUM = 1a9290c85a280a21256c96e98f2461a88481d63fc4792725845caaeb155fa623
 JAXP_SHA256SUM = 8ce48c704f38285207ee6dc56c45b2d214083b4d4d36be02901401b594ce701e
 JAXWS_SHA256SUM = 823ca6b8fd780bf1b1565a90cfc8ec6f0ee422a5d25ffb20b1ce0272dc4955aa
-JDK_SHA256SUM = 5f8b5edbebb358730425e64a31eaa11c346467ba10ffe1848f2d2ad2ea53bc3d
+JDK_SHA256SUM = a3f1748212086feb3351772c1bc3eb6a2918fac474a37bec219d97b668676f40
 LANGTOOLS_SHA256SUM = c77dd42d83f06d18fa8aa65c93d137608a2e02cf24b68fc10d7b1c0bcc12a93c
 OPENJDK_SHA256SUM = ada790b4754f521ebfad0dd909ea29b92b2b3c1b84b2e99d32673343727d95d7
 


From jvanek at redhat.com  Tue Apr  3 00:49:18 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Tue, 03 Apr 2012 09:49:18 +0200
Subject: [icedtea-web] RFC: Fix pac tests
In-Reply-To: <4F71DBE0.6040105@redhat.com>
References: <4F6D7437.8010804@redhat.com> <4F70A806.8060108@redhat.com>
	<4F70ADA7.2060707@redhat.com> <4F716946.5060900@redhat.com>
	<4F71DBE0.6040105@redhat.com>
Message-ID: <4F7AAB7E.2040902@redhat.com>

On 03/27/2012 05:25 PM, Omair Majid wrote:
> On 03/27/2012 03:16 AM, Jiri Vanek wrote:
>> Among the wrapping and other fixing you did are several times just
>> fixes of indentation. Do you mind to push those fixes separately and
>> repost the fixes you did again?
>
> Ah. Sorry for that. How does the new patch look? The file uses a really
> strange mix of tabs and spaces (both 4 and 2) for indentation, making it
> really hard to write code that fits in with the existing indentation. I
> hope I have the changes right this time.
>
> Thanks,
> Omair
>

Yap. I think this can go in.
Tyvm again!
  J.



From thomas at m3y3r.de  Tue Apr  3 03:07:02 2012
From: thomas at m3y3r.de (Thomas Meyer)
Date: Tue, 03 Apr 2012 12:07:02 +0200
Subject: [RFC] Fix IndexOutOfBoundException because of corrupted entry
	in recently_used file
In-Reply-To: <4F79A620.2090702@redhat.com>
References: <1332938501.1397.15.camel@localhost.localdomain>
	<4F79A620.2090702@redhat.com>
Message-ID: <1333447622.5010.11.camel@localhost.localdomain>

Am Montag, den 02.04.2012, 15:14 +0200 schrieb Jiri Vanek:
> On 03/28/2012 02:41 PM, Thomas Meyer wrote:
> > # HG changeset patch
> > # User Thomas Meyer<thomas at m3y3r.de>
> > # Date 1332937976 -7200
> > # Node ID f6540088f06f2d9962e1c5b7858c4212f045759e
> > # Parent  093896b370d3ed3f1fc3527084133b8e388bf0ae
> > Fix IndexOutOfBoundException because of corrupt "recently_used" index file of cached files. Better solution would be to do this validation in CacheLRUWrapper.load()
> >
> > diff -r 093896b370d3 -r f6540088f06f netx/net/sourceforge/jnlp/cache/CacheUtil.java
> > --- a/netx/net/sourceforge/jnlp/cache/CacheUtil.java	Wed Mar 28 12:08:10 2012 +0200
> > +++ b/netx/net/sourceforge/jnlp/cache/CacheUtil.java	Wed Mar 28 14:32:56 2012 +0200
> > @@ -354,17 +354,22 @@
> >
> >                   }
> >               } while (entries == null);
> > +
> >               // Start searching from the most recent to least recent.
> >               for (Entry<String, String>  e : entries) {
> >                   final String key = e.getKey();
> > -                final String path = e.getValue();
> > +                String path = e.getValue();
> >
> >                   if (path != null) {
> > -                    if (pathToURLPath(path).equals(urlPath.getPath())) { // Match found.
> > -                        cacheFile = new File(path);
> > -                        lruHandler.updateEntry(key);
> > -                        break; // Stop searching since we got newest one already.
> > -                    }
> > +                    path=pathToURLPath(path);
> > +                    if(path == null)
> > +                        lruHandler.removeEntry(key);
> > +                    else
> > +                        if (path.equals(urlPath.getPath())) { // Match found.
> > +                            cacheFile = new File(path);
> > +                            lruHandler.updateEntry(key);
> > +                            break; // Stop searching since we got newest one already.
> > +                        }
> >                   }
> >               }
> >               return cacheFile;
> > @@ -377,6 +382,13 @@
> >       private static String pathToURLPath(String path) {
> >           int len = cacheDir.length();
> >           int index = path.indexOf(File.separatorChar, len + 1);
> > +
> > +        /*
> > +         * somehow the lru entries got corrupt. ignore this entry and
> > +         * don't fail with an IndexOutOfBoundsException
> > +         */
> > +        if(index<  0)
> > +            return null;
> >           return path.substring(index);
> >       }
> >
> >
> >
> 
> Hi there! What are the prerequisites leading to do this  state?

Hi,

I'm not sure what did lead to this state. I found this nasty
constellation last friday. Maybe my browser crashed or something.

> I have fixed lru cache once already (for throwing NonIntegerValue exception) but I have never seen 
> this error even when I was trying to corrupt cache, and I agree with you that this should be done in 
> CacheLRUWrapper. Can you please provide (plaintext is enough) some reproducer?

While debugging this problem I found an entry in the recently_used file
that looked like this:

"1333048426514,0=/h"

> If you will be willing to add this behaviour to 
> icedtea-web/tests/jnlp_tests/signed/CacheReproducer/testcases/CacheReproducerTest.java it will be 
> really great (You should do this according to commit policy O:) "IcedTea-Web code changes/new 
> feature should be accompanied with appropriate tests (JUnit class and/or reproducer). If no tests 
> are added/modified, changes should be accompanied with an explanation as to why. " O:)

I will try this and post a patch the next days.

> 
>  From cache record eg.:
> 1332779007444,35=/home/user/.icedtea/cache/35/http/localhost/SetContextClassLoader.jnlp
> 
> I see that this is removing "/home/user/.icedtea/cache/" correct?

Yes, correct.

> 
> So it can fail when:
>   - recentlyused file have moved
>   - javaws was killed during writeing

I guess the saving of the recently_used file somehow did not finish.

> 
> In both cases I would prefer cleaning of cache instead of neverending removing of entry.

okay.

> 
> So after "lruHandler.removeEntry(key);" should be save() at least to prevent this to happen again 
> and again. But this brings other issues (like touching cache of other running javaws)

yes, indeed.

> 
> However, As best for fix this issue I'm considering change in CacheLRUWrapper's 
> getLRUSortedEntries() to put to value already prepared path (or object with both prepared/full paths).

I think that's the more correct thing to do.

> Then IndexOutOfBounds will be wrapped by LruCache exception and cache will be properly cleared.
> However the cleanCache() method in CacheUtil will need small fixing after this too.

Yes, probably.

> What do you think?

Sounds good to me.

btw. can the tests in the "test/jnlp_tests" directory be put in a
different directory and/or package, so I can add the "jnlp_tests"
directory to the eclipse build directory and start all tests in this
directory from the IDE? this works great for "test/netx/unit".

> 
> 
> Thank you in advance, and Tyvm for getting the issue!

my pleasure.

thomas





From ptisnovs at redhat.com  Tue Apr  3 04:21:16 2012
From: ptisnovs at redhat.com (Pavel Tisnovsky)
Date: Tue, 03 Apr 2012 13:21:16 +0200
Subject: Reviewer needed: backport of PR881 fix into IcedTea6-1.10 and
	IcedTea6-1.11
Message-ID: <4F7ADD2C.2050005@redhat.com>

Hi,

I'd like to backport PR881 fix into IcedTea6-1.10 and IcedTea6-1.11 too.
This fix has been already pushed into IcedTea6 HEAD and we have not seen
any problem with compatibility and/or performance.

hg diff generated against recent IcedTea6-1.10 and IcedTea6-1.11 is stored
in an attachment.

ChangeLog entry is the same:
2012-04-03  Pavel Tisnovsky  <ptisnovs at redhat.com>

        PR881: Sign tests (wsse.policy.basic) failures with OpenJDK6
        * Makefile.am: Updated
        * patches/idresolver_fix.patch: added patch for a class
        IdResolver.


Can anybody review this backport please?

Thank you in advance,
Pavel T.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: icedtea6-1.10.diff
Url: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120403/f2c2f602/icedtea6-1.10.diff 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: icedtea6-1.11.diff
Url: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120403/f2c2f602/icedtea6-1.11.diff 

From jvanek at redhat.com  Tue Apr  3 04:38:28 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Tue, 03 Apr 2012 13:38:28 +0200
Subject: [RFC] Fix IndexOutOfBoundException because of corrupted entry
	in recently_used file
In-Reply-To: <1333447622.5010.11.camel@localhost.localdomain>
References: <1332938501.1397.15.camel@localhost.localdomain>	
	<4F79A620.2090702@redhat.com>
	<1333447622.5010.11.camel@localhost.localdomain>
Message-ID: <4F7AE134.7080500@redhat.com>

On 04/03/2012 12:07 PM, Thomas Meyer wrote:
> Am Montag, den 02.04.2012, 15:14 +0200 schrieb Jiri Vanek:
>> On 03/28/2012 02:41 PM, Thomas Meyer wrote:
..snip..
> I'm not sure what did lead to this state. I found this nasty
> constellation last friday. Maybe my browser crashed or something.
>
Probably:)
>> I have fixed lru cache once already (for throwing NonIntegerValue exception) but I have never seen
>> this error even when I was trying to corrupt cache, and I agree with you that this should be done in
>> CacheLRUWrapper. Can you please provide (plaintext is enough) some reproducer?
>
> While debugging this problem I found an entry in the recently_used file
> that looked like this:
>
> "1333048426514,0=/h"

yes. It is the same cause as I was fixing except in my case it died as "1333048426," or ""
>
>> If you will be willing to add this behaviour to
>> icedtea-web/tests/jnlp_tests/signed/CacheReproducer/testcases/CacheReproducerTest.java it will be
>> really great (You should do this according to commit policy O:) "IcedTea-Web code changes/new
>> feature should be accompanied with appropriate tests (JUnit class and/or reproducer). If no tests
>> are added/modified, changes should be accompanied with an explanation as to why. " O:)
>
> I will try this and post a patch the next days.
>
Thank you!
>>
..snip..
>
>> Then IndexOutOfBounds will be wrapped by LruCache exception and cache will be properly cleared.
>> However the cleanCache() method in CacheUtil will need small fixing after this too.
>
> Yes, probably.
>
>> What do you think?
>
> Sounds good to me.
>
Good. As I think the reason  is same and so same  solution will serve as fix the best.
> btw. can the tests in the "test/jnlp_tests" directory be put in a
> different directory and/or package, so I can add the "jnlp_tests"
> directory to the eclipse build directory and start all tests in this
> directory from the IDE? this works great for "test/netx/unit".
I'm afraid not. But the only difference is, taht you need to add each reproducer as three directories,
  which actually doesn't mind, because one is mostly working with _one_ reproducer - debugging/coding x netx/reproducer itself
When you will add resources/srcs/testcase direcptries, all should work in IDE as you expect.

I will refer you to http://icedtea.classpath.org/wiki/Reproducers page. If you will find something unclear there, please let me know. The page is pretty fresh.

>
>>
>>
>> Thank you in advance, and Tyvm for getting the issue!
>
> my pleasure.
>
> thomas
>


Best Regards J.


From ahughes at redhat.com  Tue Apr  3 04:41:32 2012
From: ahughes at redhat.com (Andrew Hughes)
Date: Tue, 03 Apr 2012 07:41:32 -0400 (EDT)
Subject: Reviewer needed: backport of PR881 fix into IcedTea6-1.10
	and	IcedTea6-1.11
In-Reply-To: <4F7ADD2C.2050005@redhat.com>
Message-ID: <5c4fcd51-9aa2-4d85-b68a-408b5c6e7a47@zmail17.collab.prod.int.phx2.redhat.com>

----- Original Message -----
> Hi,
> 
> I'd like to backport PR881 fix into IcedTea6-1.10 and IcedTea6-1.11
> too.
> This fix has been already pushed into IcedTea6 HEAD and we have not
> seen
> any problem with compatibility and/or performance.
> 
> hg diff generated against recent IcedTea6-1.10 and IcedTea6-1.11 is
> stored
> in an attachment.
> 
> ChangeLog entry is the same:
> 2012-04-03  Pavel Tisnovsky  <ptisnovs at redhat.com>
> 
>         PR881: Sign tests (wsse.policy.basic) failures with OpenJDK6
>         * Makefile.am: Updated
>         * patches/idresolver_fix.patch: added patch for a class
>         IdResolver.
> 
> 
> Can anybody review this backport please?
> 

PR881 needs closing if it's fixed and this patch needs a NEWS update.

aph should also look at this.

> Thank you in advance,
> Pavel T.
> 
> 
> [Text File:icedtea6-1.10.diff]
> 
> 
> [Text File:icedtea6-1.11.diff]
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From ptisnovs at redhat.com  Tue Apr  3 04:46:22 2012
From: ptisnovs at redhat.com (Pavel Tisnovsky)
Date: Tue, 03 Apr 2012 13:46:22 +0200
Subject: Reviewer needed: backport of PR881 fix into IcedTea6-1.10 and
	IcedTea6-1.11
In-Reply-To: <5c4fcd51-9aa2-4d85-b68a-408b5c6e7a47@zmail17.collab.prod.int.phx2.redhat.com>
References: <5c4fcd51-9aa2-4d85-b68a-408b5c6e7a47@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <4F7AE30E.8010301@redhat.com>

Andrew Hughes wrote:
> ----- Original Message -----
>> Hi,
>>
>> I'd like to backport PR881 fix into IcedTea6-1.10 and IcedTea6-1.11
>> too.
>> This fix has been already pushed into IcedTea6 HEAD and we have not
>> seen
>> any problem with compatibility and/or performance.
>>
>> hg diff generated against recent IcedTea6-1.10 and IcedTea6-1.11 is
>> stored
>> in an attachment.
>>
>> ChangeLog entry is the same:
>> 2012-04-03  Pavel Tisnovsky  <ptisnovs at redhat.com>
>>
>>         PR881: Sign tests (wsse.policy.basic) failures with OpenJDK6
>>         * Makefile.am: Updated
>>         * patches/idresolver_fix.patch: added patch for a class
>>         IdResolver.
>>
>>
>> Can anybody review this backport please?
>>
> 
> PR881 needs closing if it's fixed and this patch needs a NEWS update.
NEWS update is part of a patch (attachment). Or do you mean we need to
change the text of the NEWS entry?

> 
> aph should also look at this.
> 
>> Thank you in advance,
>> Pavel T.
>>
>>
>> [Text File:icedtea6-1.10.diff]
>>
>>
>> [Text File:icedtea6-1.11.diff]
>>
> 



From ahughes at redhat.com  Tue Apr  3 05:02:37 2012
From: ahughes at redhat.com (Andrew Hughes)
Date: Tue, 03 Apr 2012 08:02:37 -0400 (EDT)
Subject: Reviewer needed: backport of PR881 fix into IcedTea6-1.10 and
	IcedTea6-1.11
In-Reply-To: <4F7AE30E.8010301@redhat.com>
Message-ID: <94358f30-d77d-48cd-ba5c-957a913f84b2@zmail17.collab.prod.int.phx2.redhat.com>

----- Original Message -----
> Andrew Hughes wrote:
> > ----- Original Message -----
> >> Hi,
> >>
> >> I'd like to backport PR881 fix into IcedTea6-1.10 and
> >> IcedTea6-1.11
> >> too.
> >> This fix has been already pushed into IcedTea6 HEAD and we have
> >> not
> >> seen
> >> any problem with compatibility and/or performance.
> >>
> >> hg diff generated against recent IcedTea6-1.10 and IcedTea6-1.11
> >> is
> >> stored
> >> in an attachment.
> >>
> >> ChangeLog entry is the same:
> >> 2012-04-03  Pavel Tisnovsky  <ptisnovs at redhat.com>
> >>
> >>         PR881: Sign tests (wsse.policy.basic) failures with
> >>         OpenJDK6
> >>         * Makefile.am: Updated
> >>         * patches/idresolver_fix.patch: added patch for a class
> >>         IdResolver.
> >>
> >>
> >> Can anybody review this backport please?
> >>
> > 
> > PR881 needs closing if it's fixed and this patch needs a NEWS
> > update.
> NEWS update is part of a patch (attachment). Or do you mean we need
> to
> change the text of the NEWS entry?
> 

No, I didn't see that and it's not mentioned in your ChangeLog.

> > 
> > aph should also look at this.
> > 
> >> Thank you in advance,
> >> Pavel T.
> >>
> >>
> >> [Text File:icedtea6-1.10.diff]
> >>
> >>
> >> [Text File:icedtea6-1.11.diff]
> >>
> > 
> 
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From ptisnovs at redhat.com  Tue Apr  3 05:15:11 2012
From: ptisnovs at redhat.com (Pavel Tisnovsky)
Date: Tue, 03 Apr 2012 14:15:11 +0200
Subject: Reviewer needed: backport of PR881 fix into IcedTea6-1.10 and
	IcedTea6-1.11
In-Reply-To: <94358f30-d77d-48cd-ba5c-957a913f84b2@zmail17.collab.prod.int.phx2.redhat.com>
References: <94358f30-d77d-48cd-ba5c-957a913f84b2@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <4F7AE9CF.9070706@redhat.com>

Andrew Hughes wrote:
> ----- Original Message -----
>> Andrew Hughes wrote:
>>> ----- Original Message -----
>>>> Hi,
>>>>
>>>> I'd like to backport PR881 fix into IcedTea6-1.10 and
>>>> IcedTea6-1.11
>>>> too.
>>>> This fix has been already pushed into IcedTea6 HEAD and we have
>>>> not
>>>> seen
>>>> any problem with compatibility and/or performance.
>>>>
>>>> hg diff generated against recent IcedTea6-1.10 and IcedTea6-1.11
>>>> is
>>>> stored
>>>> in an attachment.
>>>>
>>>> ChangeLog entry is the same:
>>>> 2012-04-03  Pavel Tisnovsky  <ptisnovs at redhat.com>
>>>>
>>>>         PR881: Sign tests (wsse.policy.basic) failures with
>>>>         OpenJDK6
>>>>         * Makefile.am: Updated
>>>>         * patches/idresolver_fix.patch: added patch for a class
>>>>         IdResolver.
>>>>
>>>>
>>>> Can anybody review this backport please?
>>>>
>>> PR881 needs closing if it's fixed and this patch needs a NEWS
>>> update.
>> NEWS update is part of a patch (attachment). Or do you mean we need
>> to
>> change the text of the NEWS entry?
>>
> 
> No, I didn't see that and it's not mentioned in your ChangeLog.
Oh sorry - yes you are right, should be mentioned in ChangeLog too.
> 
>>> aph should also look at this.
>>>
>>>> Thank you in advance,
>>>> Pavel T.
>>>>
>>>>
>>>> [Text File:icedtea6-1.10.diff]
>>>>
>>>>
>>>> [Text File:icedtea6-1.11.diff]
>>>>
>>
> 



From thomas at m3y3r.de  Tue Apr  3 06:14:42 2012
From: thomas at m3y3r.de (Thomas Meyer)
Date: Tue, 03 Apr 2012 15:14:42 +0200
Subject: [RFC] Fix IndexOutOfBoundException because of corrupted entry
	in recently_used file
In-Reply-To: <4F7AE134.7080500@redhat.com>
References: <1332938501.1397.15.camel@localhost.localdomain>
	<4F79A620.2090702@redhat.com>
	<1333447622.5010.11.camel@localhost.localdomain>
	<4F7AE134.7080500@redhat.com>
Message-ID: <1333458882.5010.14.camel@localhost.localdomain>

Here you go:

# HG changeset patch
# User Thomas Meyer <thomas at m3y3r.de>
# Date 1333458674 -7200
# Node ID a195e919572bce5f585f0fa1b595540519920a63
# Parent  f6540088f06f2d9962e1c5b7858c4212f045759e
Added Reproducer for corrupted cache entry file, containing an invalid path

diff -r f6540088f06f -r a195e919572b Makefile.am
--- a/Makefile.am	Wed Mar 28 14:32:56 2012 +0200
+++ b/Makefile.am	Tue Apr 03 15:11:14 2012 +0200
@@ -565,7 +565,7 @@
 	cd $(JNLP_TESTS_ENGINE_DIR) ; \
 	class_names=`cat $(REPRODUCERS_CLASS_NAMES)` ; \
 	CLASSPATH=$(NETX_DIR)/lib/classes.jar:$(JUNIT_JAR):$(JUNIT_RUNNER_JAR):. \
-	  $(BOOT_DIR)/bin/java -Dtest.server.dir=$(JNLP_TESTS_SERVER_DEPLOYDIR) -Djavaws.build.bin=$(DESTDIR)$(bindir)/javaws \
+	  $(BOOT_DIR)/bin/java -Dtest.server.dir=$(JNLP_TESTS_SERVER_DEPLOYDIR) -Djavaws.build.bin=$(DESTDIR)$(bindir)/$(javaws) \
 	 -Xbootclasspath:$(RUNTIME) CommandLine $$class_names \
 	  > stdout.log 2> stderr.log ; \
 	 cat stdout.log ; \
diff -r f6540088f06f -r a195e919572b tests/jnlp_tests/signed/CacheReproducer/testcases/CacheReproducerTest.java
--- a/tests/jnlp_tests/signed/CacheReproducer/testcases/CacheReproducerTest.java	Wed Mar 28 14:32:56 2012 +0200
+++ b/tests/jnlp_tests/signed/CacheReproducer/testcases/CacheReproducerTest.java	Tue Apr 03 15:11:14 2012 +0200
@@ -148,7 +148,7 @@
 
     @Test
     public void coruptAndRunCache2() throws Exception {
-         clearAndEvaluateCache();
+        clearAndEvaluateCache();
         evaluateSimpleTest1OkCache(runSimpleTest1());
         assertCacheIsNotEmpty();
         breakCache1();
@@ -164,6 +164,24 @@
         assertLruExceptionNOTappeared(pr2);
     }
 
+    @Test
+    public void coruptAndRunCache3() throws Exception {
+        clearAndEvaluateCache();
+        evaluateSimpleTest1OkCache(runSimpleTest1());
+        assertCacheIsNotEmpty();
+        breakCache3();
+        ProcessResult pr = runSimpleTest1();
+        assertLruExceptionAppeared(pr);
+        evaluateSimpleTest1OkCache(pr);
+        ProcessResult pr3 = runSimpleTest1();
+        evaluateSimpleTest1OkCache(pr3);
+        assertLruExceptionNOTappeared(pr3);
+        clearAndEvaluateCache();
+        ProcessResult pr2 = runSimpleTest1();
+        evaluateSimpleTest1OkCache(pr2);
+        assertLruExceptionNOTappeared(pr2);
+    }
+
     private void assertLruExceptionNOTappeared(ProcessResult pr2) {
         Assert.assertFalse("serr should NOT contain " + lre, pr2.stderr.contains(lre));
     }
@@ -174,7 +192,7 @@
 
     @Test
     public void coruptAndRunCache1Signed() throws Exception {
-         clearAndEvaluateCache();
+        clearAndEvaluateCache();
         evaluateSimpleTest1OkCache(runSimpleTest1());
         assertCacheIsNotEmpty();
         breakCache1();
@@ -189,7 +207,7 @@
 
     @Test
     public void coruptAndRunCache2Signed() throws Exception {
-         clearAndEvaluateCache();
+        clearAndEvaluateCache();
         evaluateSimpleTest1OkCache(runSimpleTest1());
         assertCacheIsNotEmpty();
         breakCache1();
@@ -236,7 +254,7 @@
     }
 
      
-    //next four tests are designed to ensure, that corupted cache wil not break already loaded cached files
+    //next four tests are designed to ensure, that corrupted cache will not break already loaded cached files
     public static final String CR1 = "CacheReproducer1";
     public static final String CR2 = "CacheReproducer2";
     public static final String CR11 = "CacheReproducer1_1";
@@ -378,6 +396,14 @@
         return s;
     }
 
+    private static String breakLastPath(String s) {
+        int i = s.lastIndexOf(home);
+        if(i >= 0 && i <= s.length() && home.length() > 4)
+            return s.substring(0, i + 3);
+
+        return null;
+    }
+
     private static void breakCache1() throws IOException {
         String s = loadCacheFile();
         s = breakAll(s);
@@ -390,6 +416,12 @@
         ServerAccess.saveFile(s, icedteaCacheFile);
     }
 
+    private static void breakCache3() throws IOException {
+        String s = loadCacheFile();
+        s = breakLastPath(s);
+        ServerAccess.saveFile(s, icedteaCacheFile);
+    }
+
     private static ServerAccess.ProcessResult runSimpleTest1() throws Exception {
         return runSimpleTest1(null, "simpletest1");
     }




From ptisnovs at redhat.com  Tue Apr  3 06:45:32 2012
From: ptisnovs at redhat.com (Pavel Tisnovsky)
Date: Tue, 03 Apr 2012 15:45:32 +0200
Subject: Reviewer needed: backport of "6792400: Avoid loading of Normalizer
	resources, for simple uses" into IcedTea6-1.10 and IcedTea6-1.11
Message-ID: <4F7AFEFC.4040701@redhat.com>

Hi,

I'd like to backport "6792400: Avoid loading of Normalizer resources, for simple uses" into IcedTea6-1.10 and
IcedTea6-1.11. This backport is already pushed in IcedTea6 HEAD (w/o problems).

hg diffs generated against recent IcedTea6-1.10 and IcedTea6-1.11 versions are stored in attachments (incl. NEWS entry).


ChangeLog entry:

2012-04-03  Pavel Tisnovsky  <ptisnovs at redhat.com>

        * patches/openjdk/6792400-Avoid_loading_Normalizer_resources.patch:
        Backport of: 6792400: Avoid loading of Normalizer resources
        for simple uses
        * NEWS: Mention backport.
        * Makefile.am: Updated


Can anybody please review these backports?

Thank you in advance,
Pavel T.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: icedtea6-1.10.patch
Type: text/x-patch
Size: 3212 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120403/b26f4cbc/icedtea6-1.10.patch 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: icedtea6-1.11.patch
Type: text/x-patch
Size: 3158 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120403/b26f4cbc/icedtea6-1.11.patch 

From jvanek at redhat.com  Tue Apr  3 07:50:28 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Tue, 03 Apr 2012 16:50:28 +0200
Subject: [RFC] Fix IndexOutOfBoundException because of corrupted entry
	in recently_used file
In-Reply-To: <1333458882.5010.14.camel@localhost.localdomain>
References: <1332938501.1397.15.camel@localhost.localdomain>		
	<4F79A620.2090702@redhat.com>	
	<1333447622.5010.11.camel@localhost.localdomain>	
	<4F7AE134.7080500@redhat.com>
	<1333458882.5010.14.camel@localhost.localdomain>
Message-ID: <4F7B0E34.7010209@redhat.com>

Thanx for test! Logic itself is good, but there are two mistakes which causes the test to be not-working.
See notes inline for them.

Do you already have commit rights? If no, do you want them? If yes - can you please contact Mark Wielaard <mjw at redhat.com>? He will ask you for your public key and grant you all necessary permissions for pushing.

Also can you please always attach patch as atatchment? Eml body is always somehow corrupted before it flows through network and can cause unnecessary errors between  keyboard and computer on that (my ;o) ) end of line.

On 04/03/2012 03:14 PM, Thomas Meyer wrote:
> Here you go:
>
> # HG changeset patch
> # User Thomas Meyer<thomas at m3y3r.de>
> # Date 1333458674 -7200
> # Node ID a195e919572bce5f585f0fa1b595540519920a63
> # Parent  f6540088f06f2d9962e1c5b7858c4212f045759e
> Added Reproducer for corrupted cache entry file, containing an invalid path
>
> diff -r f6540088f06f -r a195e919572b Makefile.am
> --- a/Makefile.am	Wed Mar 28 14:32:56 2012 +0200
> +++ b/Makefile.am	Tue Apr 03 15:11:14 2012 +0200
> @@ -565,7 +565,7 @@
>   	cd $(JNLP_TESTS_ENGINE_DIR) ; \
>   	class_names=`cat $(REPRODUCERS_CLASS_NAMES)` ; \
>   	CLASSPATH=$(NETX_DIR)/lib/classes.jar:$(JUNIT_JAR):$(JUNIT_RUNNER_JAR):. \
> -	  $(BOOT_DIR)/bin/java -Dtest.server.dir=$(JNLP_TESTS_SERVER_DEPLOYDIR) -Djavaws.build.bin=$(DESTDIR)$(bindir)/javaws \
> +	  $(BOOT_DIR)/bin/java -Dtest.server.dir=$(JNLP_TESTS_SERVER_DEPLOYDIR) -Djavaws.build.bin=$(DESTDIR)$(bindir)/$(javaws) \
Thanx for catch!
>   	 -Xbootclasspath:$(RUNTIME) CommandLine $$class_names \
>   	>  stdout.log 2>  stderr.log ; \
>   	 cat stdout.log ; \
> diff -r f6540088f06f -r a195e919572b tests/jnlp_tests/signed/CacheReproducer/testcases/CacheReproducerTest.java
> --- a/tests/jnlp_tests/signed/CacheReproducer/testcases/CacheReproducerTest.java	Wed Mar 28 14:32:56 2012 +0200
> +++ b/tests/jnlp_tests/signed/CacheReproducer/testcases/CacheReproducerTest.java	Tue Apr 03 15:11:14 2012 +0200
> @@ -148,7 +148,7 @@
>
>       @Test
>       public void coruptAndRunCache2() throws Exception {
> -         clearAndEvaluateCache();
> +        clearAndEvaluateCache();
>           evaluateSimpleTest1OkCache(runSimpleTest1());
>           assertCacheIsNotEmpty();
>           breakCache1();
> @@ -164,6 +164,24 @@
>           assertLruExceptionNOTappeared(pr2);
>       }
>
Can I ask for javadoc? I admit there is missing javadoc in rest of the testfile, but until now it was doing just one type of corruption.
> +    @Test
> +    public void coruptAndRunCache3() throws Exception {
> +        clearAndEvaluateCache();
> +        evaluateSimpleTest1OkCache(runSimpleTest1());
> +        assertCacheIsNotEmpty();
> +        breakCache3();
> +        ProcessResult pr = runSimpleTest1();
> +        assertLruExceptionAppeared(pr);
This is not correct right now. This should test for IndexOutOfBoundsException.
My opinion is to check for IndexOutOfBoundsException have not appeard and on next line assertLruExceptionAppeared - considering that your fix will print out LruException somewhere (which it should as we have agreed)
The rest of the test should be ok under same circumstances (mostly that cache will be fixed as is leading from those circumstances)
> +        evaluateSimpleTest1OkCache(pr);
> +        ProcessResult pr3 = runSimpleTest1();
> +        evaluateSimpleTest1OkCache(pr3);
> +        assertLruExceptionNOTappeared(pr3);
> +        clearAndEvaluateCache();
> +        ProcessResult pr2 = runSimpleTest1();
> +        evaluateSimpleTest1OkCache(pr2);
> +        assertLruExceptionNOTappeared(pr2);
> +    }
> +
>       private void assertLruExceptionNOTappeared(ProcessResult pr2) {
>           Assert.assertFalse("serr should NOT contain " + lre, pr2.stderr.contains(lre));
>       }
> @@ -174,7 +192,7 @@
>
>       @Test
>       public void coruptAndRunCache1Signed() throws Exception {
> -         clearAndEvaluateCache();
> +        clearAndEvaluateCache();
>           evaluateSimpleTest1OkCache(runSimpleTest1());
>           assertCacheIsNotEmpty();
>           breakCache1();
> @@ -189,7 +207,7 @@
>
>       @Test
>       public void coruptAndRunCache2Signed() throws Exception {
> -         clearAndEvaluateCache();
> +        clearAndEvaluateCache();
>           evaluateSimpleTest1OkCache(runSimpleTest1());
>           assertCacheIsNotEmpty();
>           breakCache1();
> @@ -236,7 +254,7 @@
>       }
>
>
> -    //next four tests are designed to ensure, that corupted cache wil not break already loaded cached files
> +    //next four tests are designed to ensure, that corrupted cache will not break already loaded cached files
>       public static final String CR1 = "CacheReproducer1";
>       public static final String CR2 = "CacheReproducer2";
>       public static final String CR11 = "CacheReproducer1_1";
> @@ -378,6 +396,14 @@
>           return s;
>       }
>

I'm afraid this will not work as expected. After this change the file looks like:
#netx file
#Tue Apr 03 16:26:23 CEST 2012
1333463182549,1=/home/jvanek/.icedtea/cache/1/http/localhost/simpletest1.jar
1333463182202,0=/ho

And because launched example is simpletest1, then it will be always found and the corrupted line will never be reached.
My advice here is to corrupt all lines and so be sure :)

Also maybe small test similar to assertBreakersAreWorking can be worthy, but I do not insists.
> +    private static String breakLastPath(String s) {
> +        int i = s.lastIndexOf(home);
> +        if(i>= 0&&  i<= s.length()&&  home.length()>  4)
> +            return s.substring(0, i + 3);
> +
> +        return null;
> +    }
> +
>       private static void breakCache1() throws IOException {
>           String s = loadCacheFile();
>           s = breakAll(s);
> @@ -390,6 +416,12 @@
>           ServerAccess.saveFile(s, icedteaCacheFile);
>       }
>
> +    private static void breakCache3() throws IOException {
> +        String s = loadCacheFile();
> +        s = breakLastPath(s);
> +        ServerAccess.saveFile(s, icedteaCacheFile);
> +    }
> +
>       private static ServerAccess.ProcessResult runSimpleTest1() throws Exception {
>           return runSimpleTest1(null, "simpletest1");
>       }
>
>

Best regards and thanx for effort,
   J.



From jvanek at icedtea.classpath.org  Tue Apr  3 08:06:36 2012
From: jvanek at icedtea.classpath.org (jvanek at icedtea.classpath.org)
Date: Tue, 03 Apr 2012 15:06:36 +0000
Subject: /hg/icedtea-web: Test virtual server thread marked as daeomn by ...
Message-ID: <hg.ee9b010ea74c.1333465596.8643924302249223276@icedtea.classpath.org>

changeset ee9b010ea74c in /hg/icedtea-web
details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=ee9b010ea74c
author: Jiri Vanek <jvanek at redhat.com>
date: Tue Apr 03 17:08:14 2012 +0200

	Test virtual server thread marked as daeomn by default


diffstat:

 ChangeLog                                                          |   7 +++
 tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java |  19 ++++++++-
 2 files changed, 23 insertions(+), 3 deletions(-)

diffs (69 lines):

diff -r eb3a40549623 -r ee9b010ea74c ChangeLog
--- a/ChangeLog	Mon Apr 02 11:23:18 2012 -0400
+++ b/ChangeLog	Tue Apr 03 17:08:14 2012 +0200
@@ -1,3 +1,10 @@
+2012-04-03  Jiri Vanek <jvanek at redhat.com>
+
+    Tests virtual server thread marked as daemon by default
+    * tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java:
+    All (ServerLauncher) instances returned by methods were marked as daemon
+    by default. Possibility to change and api were kept. 
+
 2012-03-30  Danesh Dadachanji  <ddadacha at redhat.com>
 
 	Certificate start dates are not being checked, they are still verified
diff -r eb3a40549623 -r ee9b010ea74c tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java
--- a/tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java	Mon Apr 02 11:23:18 2012 -0400
+++ b/tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java	Tue Apr 03 17:08:14 2012 +0200
@@ -186,9 +186,12 @@
      * usefull for testing application loading from different url then base
      */
     public static ServerLauncher getIndependentInstance() {
+        return getIndependentInstance(true);
+    }
+    public static ServerLauncher getIndependentInstance(boolean daemon) {
         String dir = (System.getProperty(TEST_SERVER_DIR));
         try{
-            return getIndependentInstance(dir, findFreePort());
+            return getIndependentInstance(dir, findFreePort(),daemon);
         }catch (Exception ex){
             throw  new RuntimeException(ex);
         }
@@ -200,9 +203,13 @@
      * @return new not cached iserver instance on random port,
      * usefull for testing application loading from different url then base
      */
+    
     public static ServerLauncher getIndependentInstance(int port) {
+        return getIndependentInstance(port, true);
+    }
+    public static ServerLauncher getIndependentInstance(int port,boolean daemon) {
         String dir = (System.getProperty(TEST_SERVER_DIR));
-        return getIndependentInstance(dir,port);
+        return getIndependentInstance(dir,port,daemon);
     }
 
     /**
@@ -210,7 +217,11 @@
      * @return new not cached iserver instance on random port upon custom www root directory,
      * usefull for testing application loading from different url then base
      */
+
     public static ServerLauncher getIndependentInstance(String dir, int port) {
+        return getIndependentInstance(dir, port, true);
+    }
+    public static ServerLauncher getIndependentInstance(String dir, int port,boolean daemon) {
 
 
         if (dir == null || dir.trim().length() == 0 || !new File(dir).exists() || !new File(dir).isDirectory()) {
@@ -218,7 +229,9 @@
         }
         try {
             ServerLauncher lServerLuncher = new ServerLauncher(port, new File(dir));
-            new Thread(lServerLuncher).start();
+            Thread r=new Thread(lServerLuncher);
+            r.setDaemon(daemon);
+            r.start();
             return lServerLuncher;
         } catch (Exception ex) {
             throw new RuntimeException(ex);


From omajid at icedtea.classpath.org  Tue Apr  3 09:13:36 2012
From: omajid at icedtea.classpath.org (omajid at icedtea.classpath.org)
Date: Tue, 03 Apr 2012 16:13:36 +0000
Subject: /hg/icedtea-web: Fix pac tests
Message-ID: <hg.60a2cbc4e542.1333469616.8643924302249223276@icedtea.classpath.org>

changeset 60a2cbc4e542 in /hg/icedtea-web
details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=60a2cbc4e542
author: Omair Majid <omajid at redhat.com>
date: Tue Apr 03 12:13:24 2012 -0400

	Fix pac tests

	The testDateRange* tests were rewritten so date wrapping is handled
	correctly. Also fixes two bugs in pac-funcs.js (a missed return value
	and using getYear instead of getFullYear).

	2012-04-03  Omair Majid  <omajid at redhat.com>

	    * netx/net/sourceforge/jnlp/runtime/pac-funcs.js: Replace incorrect use of
	    getYear() with getFullYear().
	    (inYearMonthDateRange): Add missing conditional case.
	    * tests/netx/pac/pac-funcs-test.js
	    (runTest): New function.
	    (runTests): Call runTest.
	    (incDate): Deal with month/year wrapping around.
	    (decDate): Removed.
	    (testDateRange, testDateRange2, testDateRange3): Handle wrapping of month
	    and days.


diffstat:

 ChangeLog                                      |   13 +
 netx/net/sourceforge/jnlp/runtime/pac-funcs.js |   35 +-
 tests/netx/pac/pac-funcs-test.js               |  417 +++++++++++++++---------
 3 files changed, 286 insertions(+), 179 deletions(-)

diffs (truncated from 593 to 500 lines):

diff -r ee9b010ea74c -r 60a2cbc4e542 ChangeLog
--- a/ChangeLog	Tue Apr 03 17:08:14 2012 +0200
+++ b/ChangeLog	Tue Apr 03 12:13:24 2012 -0400
@@ -1,3 +1,16 @@
+2012-04-03  Omair Majid  <omajid at redhat.com>
+
+	* netx/net/sourceforge/jnlp/runtime/pac-funcs.js: Replace incorrect use of
+	getYear() with getFullYear().
+	(inYearMonthDateRange): Add missing conditional case.
+	* tests/netx/pac/pac-funcs-test.js
+	(runTest): New function.
+	(runTests): Call runTest.
+	(incDate): Deal with month/year wrapping around.
+	(decDate): Removed.
+	(testDateRange, testDateRange2, testDateRange3): Handle wrapping of month
+	and days.
+
 2012-04-03  Jiri Vanek <jvanek at redhat.com>
 
     Tests virtual server thread marked as daemon by default
diff -r ee9b010ea74c -r 60a2cbc4e542 netx/net/sourceforge/jnlp/runtime/pac-funcs.js
--- a/netx/net/sourceforge/jnlp/runtime/pac-funcs.js	Tue Apr 03 17:08:14 2012 +0200
+++ b/netx/net/sourceforge/jnlp/runtime/pac-funcs.js	Tue Apr 03 12:13:24 2012 -0400
@@ -338,7 +338,7 @@
     }
 }
 
-    function isDateInRange() {
+function isDateInRange() {
 
     function isDate(date) {
         if (typeof(date) === 'number' && (date <= 31 && date >= 1)) {
@@ -415,7 +415,7 @@
     }
 
     function inYearRange(today, year1, year2) {
-        if (year1 <= today.getYear() && today.getYear() <= year2) {
+        if (year1 <= today.getFullYear() && today.getFullYear() <= year2) {
             return true;
         } else {
             return false;
@@ -482,7 +482,7 @@
 
     function inYearMonthRange(today, month1, year1, month2, year2) {
         if (year1 === year2) {
-            if (today.getYear() === year1) {
+            if (today.getFullYear() === year1) {
                if (month1 <= today.getMonth() && today.getMonth() <= month2) {
                    return true;
                } else {
@@ -493,14 +493,14 @@
             }
         }
         if (year1 < year2) {
-            if (year1 <= today.getYear() && today.getYear() <= year2) {
-                if (today.getYear() === year1) {
+            if (year1 <= today.getFullYear() && today.getFullYear() <= year2) {
+                if (today.getFullYear() === year1) {
                     if (today.getMonth() >= month1) {
                         return true;
                     } else {
                         return false;
                     }
-                } else if (today.getYear() === year2) {
+                } else if (today.getFullYear() === year2) {
                     if (today.getMonth() <= month2) {
                         return true;
                     } else {
@@ -515,12 +515,11 @@
         } else {
             return false;
         }
-
     }
 
     function inYearMonthDateRange(today, date1, month1, year1, date2, month2, year2) {
         if (year1 === year2) {
-            if (year1 === today.getYear()) {
+            if (year1 === today.getFullYear()) {
                 if ((month1 <= today.getMonth()) && (today.getMonth() <= month2)) {
                     if (month1 === month2) {
                         if (date1 <= today.getDate() && today.getDate() <= date2) {
@@ -550,8 +549,8 @@
                 return false;
             }
         } else if (year1 < year2) {
-            if (year1 <= today.getYear() && today.getYear() <= year2) {
-                if (today.getYear() === year1) {
+            if (year1 <= today.getFullYear() && today.getFullYear() <= year2) {
+                if (today.getFullYear() === year1) {
                     if (today.getMonth() === month1) {
                         if (today.getDate() >= date1) {
                             return true;
@@ -563,11 +562,17 @@
                     } else {
                         return false;
                     }
-                } else if (today.getYear() === year2) {
-                    if (today.getMonth() <= month2) {
-
+                } else if (today.getFullYear() === year2) {
+                    if (today.getMonth() === month2) {
+                        if (today.getDate() <= date1) {
+                            return true;
+                        } else {
+                            return false;
+                        }
+                    } else if (today.getMonth() < month2) {
+                        return true;
                     } else {
-                        return true;
+                        return false;
                     }
                 } else {
                     return true;
@@ -617,7 +622,7 @@
                     return false;
                 }
             } else { // year
-                if (today.getYear() === arg) {
+                if (today.getFullYear() === arg) {
                     return true;
                 } else {
                     return false;
diff -r ee9b010ea74c -r 60a2cbc4e542 tests/netx/pac/pac-funcs-test.js
--- a/tests/netx/pac/pac-funcs-test.js	Tue Apr 03 17:08:14 2012 +0200
+++ b/tests/netx/pac/pac-funcs-test.js	Tue Apr 03 12:13:24 2012 -0400
@@ -31,30 +31,32 @@
 }
 
 function runTests(name, tests) {
-
 	var undefined_var;
-
 	for ( var i = 0; i < tests.length; i++) {
-
-		var expectedVal = tests[i][0];
-		var args = tests[i].slice(1);
-		var returnVal;
-		try {
-			returnVal = name.apply(null, args);
-		} catch (e) {
-			returnVal = e;
-		}
-		if (returnVal === expectedVal) {
-			java.lang.System.out.println("Passed: " + name.name + "(" + args.join(", ") + ")");
-			testsPassed++;
-		} else {
-			java.lang.System.out.println("FAILED: " + name.name + "(" + args.join(", ") + ")");
-			java.lang.System.out.println("        Expected '" + expectedVal + "' but got '" + returnVal + "'");
-			testsFailed++;
-		}
+		runTest(name, tests[i]);
 	}
 }
 
+function runTest(name, test) {
+    var expectedVal = test[0];
+    var args = test.slice(1);
+    var returnVal;
+    try {
+        returnVal = name.apply(null, args);
+    } catch (e) {
+        returnVal = e;
+    }
+    if (returnVal === expectedVal) {
+        java.lang.System.out.println("Passed: " + name.name + "(" + args.join(", ") + ")");
+        testsPassed++;
+    } else {
+        java.lang.System.out.println("FAILED: " + name.name + "(" + args.join(", ") + ")");
+        java.lang.System.out.println("        Expected '" + expectedVal + "' but got '" + returnVal + "'");
+        testsFailed++;
+    }
+}
+
+
 function testIsPlainHostName() {
     var tests = [
         [ false, "icedtea.classpath.org" ],
@@ -241,136 +243,227 @@
     runTests(weekdayRange, tests);
 }
 
-    function incDate(date) {
-        return (date + 1 - 1) % 31 +1 ;
+/** Returns an array: [day, month, year] */
+function incDate() {
+    if ((arguments.length >= 3) && (arguments.length % 2 === 1)) {
+        var date = arguments[0];
+        var result = date;
+        var index = 1;
+        while (index < arguments.length) {
+            var whichThing = arguments[index];
+            var by = arguments[index+1];
+            switch (whichThing) {
+                case 'year':
+                    result = new Date(result.getFullYear()+by, result.getMonth(), result.getDate());
+                    break;
+                case 'month':
+                    result = new Date(result.getFullYear(), result.getMonth()+by, result.getDate());
+                    break;
+                case 'day':
+                    result = new Date(result.getFullYear(), result.getMonth(), result.getDate()+by);
+                    break;
+            }
+            index += 2;
+        }
+        return [result.getDate(), result.getMonth(), result.getFullYear()];
+    }
+    throw "Please call incDate properly";
+}
+
+function monthToStr(month) {
+    switch (month) {
+        case -1: return "DEC";
+        case 0: return "JAN";
+        case 1: return "FEB";
+        case 2: return "MAR";
+        case 3: return "APR";
+        case 4: return "MAY";
+        case 5: return "JUN";
+        case 6: return "JUL";
+        case 7: return "AUG";
+        case 8: return "SEP";
+        case 9: return "OCT";
+        case 10: return "NOV";
+        case 11: return "DEC";
+        case 12: return "JAN";
+        default: throw "Invalid Month" + month;
+    }
+}
+
+function testDateRange() {
+
+    {
+        var current = new Date();
+        var date = current.getDate();
+        var month = current.getMonth();
+        var year = current.getFullYear();
+
+        var today = incDate(current, 'day', 0);
+        var tomorrow = incDate(current, 'day', 1);
+        var yesterday = incDate(current, 'day', -1);
+
+        runTest(dateRange, [ true, date ]);
+        runTest(dateRange, [ false, tomorrow[0] ]);
+        runTest(dateRange, [ false, yesterday[0] ]);
+
+        runTest(dateRange, [ true, monthToStr(month) ]);
+        runTest(dateRange, [ false, monthToStr(month+1) ]);
+        runTest(dateRange, [ false, monthToStr(month-1) ]);
+
+        runTest(dateRange, [ true, year ]);
+        runTest(dateRange, [ false, year - 1]);
+        runTest(dateRange, [ false, year + 1]);
+
+        runTest(dateRange, [ true, date, date ]);
+        runTest(dateRange, [ true, today[0], tomorrow[0] ]);
+        runTest(dateRange, [ true, yesterday[0], today[0] ]);
+        runTest(dateRange, [ true, yesterday[0], tomorrow[0] ]);
+        runTest(dateRange, [ false, tomorrow[0], yesterday[0] ]);
+        runTest(dateRange, [ false, incDate(current,'day',-2)[0], yesterday[0] ]);
+        runTest(dateRange, [ false, tomorrow[0], incDate(current,'day',2)[0] ]);
+
+        runTest(dateRange, [ true, monthToStr(month), monthToStr(month) ]);
+        runTest(dateRange, [ true, monthToStr(month), monthToStr(month+1) ]);
+        runTest(dateRange, [ true, monthToStr(month-1), monthToStr(month) ]);
+        runTest(dateRange, [ true, monthToStr(month-1), monthToStr(month+1) ]);
+        runTest(dateRange, [ true, "JAN", "DEC" ]);
+        runTest(dateRange, [ true, "FEB", "JAN" ]);
+        runTest(dateRange, [ true, "DEC", "NOV" ]);
+        runTest(dateRange, [ true, "JUL", "JUN"]);
+        runTest(dateRange, [ false, monthToStr(month+1), monthToStr(month+1) ]);
+        runTest(dateRange, [ false, monthToStr(month-1), monthToStr(month-1) ]);
+        runTest(dateRange, [ false, monthToStr(month+1), monthToStr(month-1) ]);
+
+        runTest(dateRange, [ true, year, year ]);
+        runTest(dateRange, [ true, year, year+1 ]);
+        runTest(dateRange, [ true, year-1, year ]);
+        runTest(dateRange, [ true, year-1, year+1 ]);
+        runTest(dateRange, [ false, year-2, year-1 ]);
+        runTest(dateRange, [ false, year+1, year+1 ]);
+        runTest(dateRange, [ false, year+1, year+2 ]);
+        runTest(dateRange, [ false, year+1, year-1 ]);
+
+        runTest(dateRange, [ true, date, monthToStr(month) , date, monthToStr(month) ]);
+        runTest(dateRange, [ true, yesterday[0], monthToStr(yesterday[1]) , date, monthToStr(month) ]);
+        runTest(dateRange, [ false, yesterday[0], monthToStr(yesterday[1]) , yesterday[0], monthToStr(yesterday[1]) ]);
+        runTest(dateRange, [ true, date, monthToStr(month) , tomorrow[0], monthToStr(tomorrow[1]) ]);
+        runTest(dateRange, [ false, tomorrow[0], monthToStr(tomorrow[1]) , tomorrow[0], monthToStr(tomorrow[1]) ]);
+        runTest(dateRange, [ true, yesterday[0], monthToStr(yesterday[1]) , tomorrow[0], monthToStr(tomorrow[1]) ]);
+        runTest(dateRange, [ false, tomorrow[0], monthToStr(tomorrow[1]) , yesterday[0], monthToStr(yesterday[1]) ]);
     }
 
-    function decDate(date) {
-        return (date - 1 - 1 + 31) % 31 + 1;
+    {
+        var lastMonth = incDate(new Date(), 'month', -1);
+        var thisMonth = incDate(new Date(), 'month', 0);
+        var nextMonth = incDate(new Date(), 'month', +1);
+        runTest(dateRange, [ true, lastMonth[0], monthToStr(lastMonth[1]) , thisMonth[0], monthToStr(thisMonth[1]) ]);
+        runTest(dateRange, [ true, thisMonth[0], monthToStr(thisMonth[1]) , nextMonth[0], monthToStr(nextMonth[1]) ]);
+        runTest(dateRange, [ true, lastMonth[0], monthToStr(lastMonth[1]) , nextMonth[0], monthToStr(nextMonth[1]) ]);
+        var date1 = incDate(new Date(), 'day', +1, 'month', -1);
+        var date2 = incDate(new Date(), 'day', -1, 'month', +1);
+        runTest(dateRange, [ true, date1[0], monthToStr(date1[1]) , nextMonth[0], monthToStr(nextMonth[1]) ]);
+        runTest(dateRange, [ true, lastMonth[0], monthToStr(lastMonth[1]) , date2[0], monthToStr(date2[1]) ]);
+        runTest(dateRange, [ false, nextMonth[0], monthToStr(nextMonth[1]) , lastMonth[0], monthToStr(lastMonth[1]) ]);
+        var date3 = incDate(new Date(), 'day', +1, 'month', +1);
+        var date4 = incDate(new Date(), 'day', +1, 'month', -1);
+        runTest(dateRange, [ false, date3[0], monthToStr(date3[1]) , date4[0], monthToStr(date4[1]) ]);
+
+        var date5 = incDate(new Date(), 'day', -1, 'month', -1);
+        runTest(dateRange, [ false, date2[0], monthToStr(date2[1]) , date5[0], monthToStr(date5[1]) ]);
+
+        runTest(dateRange, [ true, 1, "JAN", 31, "DEC" ]);
+        runTest(dateRange, [ true, 2, "JAN", 1, "JAN" ]);
+
+        var month = new Date().getMonth();
+        runTest(dateRange, [ false, 1, monthToStr(month+1), 31, monthToStr(month+1) ]);
+        runTest(dateRange, [ false, 1, monthToStr(month-1), 31, monthToStr(month-1) ]);
     }
 
-    function monthToStr(month) {
-        switch (month) {
-            case -1: return "DEC";
-            case 0: return "JAN";
-            case 1: return "FEB";
-            case 2: return "MAR";
-            case 3: return "APR";
-            case 4: return "MAY";
-            case 5: return "JUN";
-            case 6: return "JUL";
-            case 7: return "AUG";
-            case 8: return "SEP";
-            case 9: return "OCT";
-            case 10: return "NOV";
-            case 11: return "DEC";
-            case 12: return "JAN";
-            default: throw "Invalid Month";
-        }
+
+    {
+        var lastMonth = incDate(new Date(), 'month', -1);
+        var thisMonth = incDate(new Date(), 'month', 0);
+        var nextMonth = incDate(new Date(), 'month', +1);
+        runTest(dateRange, [ true, monthToStr(thisMonth[1]), thisMonth[2], monthToStr(thisMonth[1]), thisMonth[2] ]);
+        runTest(dateRange, [ true, monthToStr(lastMonth[1]), lastMonth[2], monthToStr(thisMonth[1]), thisMonth[2] ]);
+        runTest(dateRange, [ true, monthToStr(thisMonth[1]), thisMonth[2], monthToStr(nextMonth[1]), nextMonth[2] ]);
+        runTest(dateRange, [ true, monthToStr(lastMonth[1]), lastMonth[2], monthToStr(nextMonth[1]), nextMonth[2] ]);
+        runTest(dateRange, [ true, monthToStr(0), year, monthToStr(11), year ]);
+
+        runTest(dateRange, [ false, monthToStr(nextMonth[1]), nextMonth[2], monthToStr(lastMonth[1]), lastMonth[2] ]);
+        runTest(dateRange, [ false, monthToStr(nextMonth[1]), nextMonth[2], monthToStr(nextMonth[1]), nextMonth[2] ]);
+        runTest(dateRange, [ false, monthToStr(lastMonth[1]), lastMonth[2], monthToStr(lastMonth[1]), lastMonth[2] ]);
+
+        var lastYear = incDate(new Date(), 'year', -1);
+        var nextYear = incDate(new Date(), 'year', +1);
+
+        runTest(dateRange, [ false, monthToStr(lastYear[1]), lastYear[2], monthToStr(lastMonth[1]), lastMonth[2] ]);
+        runTest(dateRange, [ true, monthToStr(thisMonth[1]), thisMonth[2], monthToStr(nextYear[1]), nextYear[2] ]);
+
+        var year = new Date().getFullYear();
+        var month = new Date().getMonth();
+
+        runTest(dateRange, [ true, monthToStr(month), year-1, monthToStr(month), year ]);
+        runTest(dateRange, [ true, monthToStr(month), year-1, monthToStr(month), year+1 ]);
+        runTest(dateRange, [ true, monthToStr(0), year, monthToStr(0), year+1 ]);
+        runTest(dateRange, [ true, monthToStr(0), year-1, monthToStr(0), year+1 ]);
+        runTest(dateRange, [ false, monthToStr(0), year-1, monthToStr(11), year-1 ]);
+        runTest(dateRange, [ false, monthToStr(0), year+1, monthToStr(11), year+1 ]);
     }
 
-function testDateRange() {
-   
+    {
+        var today = incDate(new Date(), 'day', 0);
+        var yesterday = incDate(new Date(), 'day', -1);
+        var tomorrow = incDate(new Date(), 'day', +1);
+        runTest(dateRange, [ true,
+            today[0], monthToStr(today[1]), today[2], today[0], monthToStr(today[1]), today[2] ]);
+        runTest(dateRange, [ true,
+            yesterday[0], monthToStr(yesterday[1]), yesterday[2], tomorrow[0], monthToStr(tomorrow[1]), tomorrow[2] ]);
+    }
 
-    var today = new Date();
-    var date = today.getDate();
-    var month = today.getMonth();
-    var year = today.getYear();
+    {
+        var dayLastMonth = incDate(new Date(), 'day', -1, 'month', -1);
+        var dayNextMonth = incDate(new Date(), 'day', +1, 'month', +1);
+        runTest(dateRange, [ true,
+            dayLastMonth[0], monthToStr(dayLastMonth[1]), dayLastMonth[2], dayNextMonth[0], monthToStr(dayNextMonth[1]), dayNextMonth[2] ]);
+    }
 
-    var tests = [
-        [ true, date ],
-        [ false, incDate(date) ],
-        [ false, decDate(date) ],
+    {
+        var dayLastYear = incDate(new Date(), 'day', -1, 'month', -1, 'year', -1);
+        var dayNextYear = incDate(new Date(), 'day', +1, 'month', +1, 'year', +1);
+        runTest(dateRange, [ true,
+            dayLastYear[0], monthToStr(dayLastYear[1]), dayLastYear[2], dayNextYear[0], monthToStr(dayNextYear[1]), dayNextYear[2] ]);
+    }
 
-        [ true, monthToStr(month) ],
-        [ false, monthToStr(month+1) ],
-        [ false, monthToStr(month-1) ],
+    {
+        var dayLastYear = incDate(new Date(), 'day', +1, 'month', -1, 'year', -1);
+        var dayNextYear = incDate(new Date(), 'day', +1, 'month', +1, 'year', +1);
+        runTest(dateRange, [ true,
+            dayLastYear[0], monthToStr(dayLastYear[1]), dayLastYear[2], dayNextYear[0], monthToStr(dayNextYear[1]), dayNextYear[2] ]);
+    }
 
-        [ true, year ],
-        [ false, year - 1],
-        [ false, year + 1],
+    {
+        var tomorrow = incDate(new Date(), 'day', +1);
+        var dayNextYear = incDate(new Date(), 'day', +1, 'month', +1, 'year', +1);
+        runTest(dateRange, [ false,
+            tomorrow[0], monthToStr(tomorrow[1]), tomorrow[2], dayNextYear[0], monthToStr(dayNextYear[1]), dayNextYear[2] ]);
 
-        [ true, date, date ],
-        [ true, date, incDate(date) ],
-        [ true, decDate(date), date ],
-        [ true, decDate(date), incDate(date) ],
-        [ false, incDate(date), decDate(date) ],
-        [ false, decDate(decDate(date)), decDate(date) ],
-        [ false, incDate(date), incDate(incDate(date)) ],
+    }
 
-        [ true, monthToStr(month), monthToStr(month) ],
-        [ true, monthToStr(month), monthToStr(month+1) ],
-        [ true, monthToStr(month-1), monthToStr(month) ],
-        [ true, monthToStr(month-1), monthToStr(month+1) ],
-        [ true, "JAN", "DEC" ],
-        [ true, "DEC", "NOV" ],
-        [ true, "JUL", "JUN"],
-        [ false, monthToStr(month+1), monthToStr(month+1) ],
-        [ false, monthToStr(month-1), monthToStr(month-1) ],
-        [ false, monthToStr(month+1), monthToStr(month-1) ],
+    {
+        var nextMonth = incDate(new Date(), 'month', +1);
+        var nextYear = incDate(new Date(), 'day', +1, 'month', +1, 'year', +1);
+        runTest(dateRange, [ false,
+            nextMonth[0], monthToStr(nextMonth[1]), nextMonth[2], nextYear[0], monthToStr(nextYear[1]), nextYear[2] ]);
+    }
 
-        [ true, year, year ],
-        [ true, year, year+1 ],
-        [ true, year-1, year ],
-        [ true, year-1, year+1 ],
-        [ false, year-2, year-1 ],
-        [ false, year+1, year+1 ],
-        [ false, year+1, year+2 ],
-        [ false, year+1, year-1 ],
-
-        [ true, date, monthToStr(month) , date, monthToStr(month) ],
-        [ true, decDate(date), monthToStr(month) , date, monthToStr(month) ],
-        [ false, decDate(date), monthToStr(month) , decDate(date), monthToStr(month) ],
-        [ true, date, monthToStr(month) , incDate(date), monthToStr(month) ],
-        [ false, incDate(date), monthToStr(month) , incDate(date), monthToStr(month) ],
-        [ true, decDate(date), monthToStr(month) , incDate(date), monthToStr(month) ],
-        [ false, incDate(date), monthToStr(month) , decDate(date), monthToStr(month) ],
-        [ true, date, monthToStr(month-1) , date, monthToStr(month) ],
-        [ true, date, monthToStr(month) , date, monthToStr(month+1) ],
-        [ true, date, monthToStr(month-1) , date, monthToStr(month+1) ],
-        [ true, incDate(date), monthToStr(month-1) , date, monthToStr(month+1) ],
-        [ true, date, monthToStr(month-1) , decDate(date), monthToStr(month+1) ],
-        [ false, date, monthToStr(month+1) , date, monthToStr(month-1) ],
-        [ false, incDate(date), monthToStr(month+1) , incDate(date), monthToStr(month-1) ],
-        [ false, decDate(date), monthToStr(month+1) , decDate(date), monthToStr(month-1) ],
-        [ true, 1, "JAN", 31, "DEC" ],
-        [ true, 2, "JAN", 1, "JAN" ],
-        [ false, 1, monthToStr(month+1), 31, monthToStr(month+1) ],
-        [ false, 1, monthToStr(month-1), 31, monthToStr(month-1) ],
-
-        [ true, monthToStr(month), year, monthToStr(month), year ],
-        [ true, monthToStr(month-1), year, monthToStr(month), year ],
-        [ true, monthToStr(month), year, monthToStr(month+1), year ],
-        [ true, monthToStr(month-1), year, monthToStr(month+1), year ],
-        [ true, monthToStr(0), year, monthToStr(11), year ],
-        [ false, monthToStr(month+1), year, monthToStr(month-1), year ],
-        [ false, monthToStr(month+1), year, monthToStr(month+1), year ],
-        [ false, monthToStr(month-1), year, monthToStr(month-1), year ],
-        [ false, monthToStr(month), year-1, monthToStr(month-1), year ],
-        [ true, monthToStr(month), year, monthToStr(month), year + 1 ],
-        [ true, monthToStr(month), year-1, monthToStr(month), year ],
-        [ true, monthToStr(month), year-1, monthToStr(month), year+1 ],
-        [ true, monthToStr(0), year, monthToStr(0), year+1 ],
-        [ true, monthToStr(0), year-1, monthToStr(0), year+1 ],
-        [ false, monthToStr(0), year-1, monthToStr(11), year-1 ],
-        [ false, monthToStr(0), year+1, monthToStr(11), year+1 ],
-
-        [ true, date, monthToStr(month), year, date, monthToStr(month), year ],
-        [ true, decDate(date), monthToStr(month), year, incDate(date), monthToStr(month), year ],


From omajid at redhat.com  Tue Apr  3 09:14:20 2012
From: omajid at redhat.com (Omair Majid)
Date: Tue, 03 Apr 2012 12:14:20 -0400
Subject: [icedtea-web] RFC: Fix pac tests
In-Reply-To: <4F7AAB7E.2040902@redhat.com>
References: <4F6D7437.8010804@redhat.com> <4F70A806.8060108@redhat.com>
	<4F70ADA7.2060707@redhat.com> <4F716946.5060900@redhat.com>
	<4F71DBE0.6040105@redhat.com> <4F7AAB7E.2040902@redhat.com>
Message-ID: <4F7B21DC.5090406@redhat.com>

On 04/03/2012 03:49 AM, Jiri Vanek wrote:
> On 03/27/2012 05:25 PM, Omair Majid wrote:
>> On 03/27/2012 03:16 AM, Jiri Vanek wrote:
>>> Among the wrapping and other fixing you did are several times just
>>> fixes of indentation. Do you mind to push those fixes separately and
>>> repost the fixes you did again?
>>
>> Ah. Sorry for that. How does the new patch look? The file uses a really
>> strange mix of tabs and spaces (both 4 and 2) for indentation, making it
>> really hard to write code that fits in with the existing indentation. I
>> hope I have the changes right this time.
> 
> Yap. I think this can go in.

Thanks for the review. Pushed to HEAD:
http://icedtea.classpath.org/hg/icedtea-web/rev/60a2cbc4e542

Cheers,
Omair


From ddadacha at redhat.com  Tue Apr  3 11:13:44 2012
From: ddadacha at redhat.com (Danesh Dadachanji)
Date: Tue, 03 Apr 2012 14:13:44 -0400
Subject: [RFC][icedtea-web] Use IcedTea as the vendor for all JNLPs in test
	suite
Message-ID: <4F7B3DD8.80904@redhat.com>

Hi,

Many of the JNLPs in the test suite have various vendors (for no particular reason). For the community's sake, I'd like to replace all 
the ones under tests/jnlp_tests/ with IcedTea. I'm avoiding touching the unit test ones because I'm not 100% sure the vendor's being 
specified explicitly to be tested.

This command should do the trick:
$ find ./icedtea-web/tests/jnlp_tests/ -name *\.jnlp -exec sed -ie 's/<vendor>[A-Za-z0-9 ]*<\/vendor>/<vendor>IcedTea<\/vendor>/g' {} \;

The attached patch has the result, the above worked as expected.

Okay to push to HEAD?

Cheers,
Danesh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: replace-vendor-with-icedtea.patch
Type: text/x-patch
Size: 40557 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120403/8c10c3a9/replace-vendor-with-icedtea.patch 

From jvanek at redhat.com  Tue Apr  3 12:02:33 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Tue, 03 Apr 2012 21:02:33 +0200
Subject: [rfc][icedtea-web] virtual server thread marked as daemon by
	default
In-Reply-To: <20120402202512.GD5567@redhat.com>
References: <4F6B1827.9060207@redhat.com> <20120402202512.GD5567@redhat.com>
Message-ID: <4F7B4949.3070605@redhat.com>

On 04/02/2012 10:25 PM, Deepak Bhole wrote:
> * Jiri Vanek<jvanek at redhat.com>  [2012-03-22 08:16]:
>> although junit was handling "redundant" threads pretty well, I think it is correct thing to do
>>
>> Any reason why not?	
>>
>> 2012-03-22  Jiri Vanek<jvanek at redhat.com>
>>
>> 	test's virtual server thread marked as daemon by default
>
> "test's" ->  "Tests"
>
> After that, OK for 1.2 (if applicable) and HEAD.

Hi! Pushed to head. Thanx a lot! I would rather stay away from pushing to 1.2 unless you have some objections.

J.
>
> Cheers,
> Deepak
>
>> 	* tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java:
>> 	All (ServerLauncher) instances returned by methods were marked as daemon
>> 	by default. Possibility to change and api were kept.
>
>> diff -r 89609d0a4e1c tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java
>> --- a/tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java	Mon Mar 19 14:37:03 2012 -0400
>> +++ b/tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java	Thu Mar 22 12:20:47 2012 +0100
>> @@ -186,9 +186,12 @@
>>        * usefull for testing application loading from different url then base
>>        */
>>       public static ServerLauncher getIndependentInstance() {
>> +        return getIndependentInstance(true);
>> +    }
>> +    public static ServerLauncher getIndependentInstance(boolean daemon) {
>>           String dir = (System.getProperty(TEST_SERVER_DIR));
>>           try{
>> -            return getIndependentInstance(dir, findFreePort());
>> +            return getIndependentInstance(dir, findFreePort(),daemon);
>>           }catch (Exception ex){
>>               throw  new RuntimeException(ex);
>>           }
>> @@ -200,9 +203,13 @@
>>        * @return new not cached iserver instance on random port,
>>        * usefull for testing application loading from different url then base
>>        */
>> +
>>       public static ServerLauncher getIndependentInstance(int port) {
>> +        return getIndependentInstance(port, true);
>> +    }
>> +    public static ServerLauncher getIndependentInstance(int port,boolean daemon) {
>>           String dir = (System.getProperty(TEST_SERVER_DIR));
>> -        return getIndependentInstance(dir,port);
>> +        return getIndependentInstance(dir,port,daemon);
>>       }
>>
>>       /**
>> @@ -210,7 +217,11 @@
>>        * @return new not cached iserver instance on random port upon custom www root directory,
>>        * usefull for testing application loading from different url then base
>>        */
>> +
>>       public static ServerLauncher getIndependentInstance(String dir, int port) {
>> +        return getIndependentInstance(dir, port, true);
>> +    }
>> +    public static ServerLauncher getIndependentInstance(String dir, int port,boolean daemon) {
>>
>>
>>           if (dir == null || dir.trim().length() == 0 || !new File(dir).exists() || !new File(dir).isDirectory()) {
>> @@ -218,7 +229,9 @@
>>           }
>>           try {
>>               ServerLauncher lServerLuncher = new ServerLauncher(port, new File(dir));
>> -            new Thread(lServerLuncher).start();
>> +            Thread r=new Thread(lServerLuncher);
>> +            r.setDaemon(daemon);
>> +            r.start();
>>               return lServerLuncher;
>>           } catch (Exception ex) {
>>               throw new RuntimeException(ex);
>



From dbhole at redhat.com  Tue Apr  3 12:05:09 2012
From: dbhole at redhat.com (Deepak Bhole)
Date: Tue, 3 Apr 2012 15:05:09 -0400
Subject: [rfc][icedtea-web] virtual server thread marked as daemon by
	default
In-Reply-To: <4F7B4949.3070605@redhat.com>
References: <4F6B1827.9060207@redhat.com> <20120402202512.GD5567@redhat.com>
	<4F7B4949.3070605@redhat.com>
Message-ID: <20120403190508.GG28015@redhat.com>

* Jiri Vanek <jvanek at redhat.com> [2012-04-03 14:59]:
> On 04/02/2012 10:25 PM, Deepak Bhole wrote:
> >* Jiri Vanek<jvanek at redhat.com>  [2012-03-22 08:16]:
> >>although junit was handling "redundant" threads pretty well, I think it is correct thing to do
> >>
> >>Any reason why not?	
> >>
> >>2012-03-22  Jiri Vanek<jvanek at redhat.com>
> >>
> >>	test's virtual server thread marked as daemon by default
> >
> >"test's" ->  "Tests"
> >
> >After that, OK for 1.2 (if applicable) and HEAD.
> 
> Hi! Pushed to head. Thanx a lot! I would rather stay away from pushing to 1.2 unless you have some objections.
> 


No objections. Thanks!

Deepak

> J.
> >
> >Cheers,
> >Deepak
> >
> >>	* tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java:
> >>	All (ServerLauncher) instances returned by methods were marked as daemon
> >>	by default. Possibility to change and api were kept.
> >
> >>diff -r 89609d0a4e1c tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java
> >>--- a/tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java	Mon Mar 19 14:37:03 2012 -0400
> >>+++ b/tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java	Thu Mar 22 12:20:47 2012 +0100
> >>@@ -186,9 +186,12 @@
> >>       * usefull for testing application loading from different url then base
> >>       */
> >>      public static ServerLauncher getIndependentInstance() {
> >>+        return getIndependentInstance(true);
> >>+    }
> >>+    public static ServerLauncher getIndependentInstance(boolean daemon) {
> >>          String dir = (System.getProperty(TEST_SERVER_DIR));
> >>          try{
> >>-            return getIndependentInstance(dir, findFreePort());
> >>+            return getIndependentInstance(dir, findFreePort(),daemon);
> >>          }catch (Exception ex){
> >>              throw  new RuntimeException(ex);
> >>          }
> >>@@ -200,9 +203,13 @@
> >>       * @return new not cached iserver instance on random port,
> >>       * usefull for testing application loading from different url then base
> >>       */
> >>+
> >>      public static ServerLauncher getIndependentInstance(int port) {
> >>+        return getIndependentInstance(port, true);
> >>+    }
> >>+    public static ServerLauncher getIndependentInstance(int port,boolean daemon) {
> >>          String dir = (System.getProperty(TEST_SERVER_DIR));
> >>-        return getIndependentInstance(dir,port);
> >>+        return getIndependentInstance(dir,port,daemon);
> >>      }
> >>
> >>      /**
> >>@@ -210,7 +217,11 @@
> >>       * @return new not cached iserver instance on random port upon custom www root directory,
> >>       * usefull for testing application loading from different url then base
> >>       */
> >>+
> >>      public static ServerLauncher getIndependentInstance(String dir, int port) {
> >>+        return getIndependentInstance(dir, port, true);
> >>+    }
> >>+    public static ServerLauncher getIndependentInstance(String dir, int port,boolean daemon) {
> >>
> >>
> >>          if (dir == null || dir.trim().length() == 0 || !new File(dir).exists() || !new File(dir).isDirectory()) {
> >>@@ -218,7 +229,9 @@
> >>          }
> >>          try {
> >>              ServerLauncher lServerLuncher = new ServerLauncher(port, new File(dir));
> >>-            new Thread(lServerLuncher).start();
> >>+            Thread r=new Thread(lServerLuncher);
> >>+            r.setDaemon(daemon);
> >>+            r.start();
> >>              return lServerLuncher;
> >>          } catch (Exception ex) {
> >>              throw new RuntimeException(ex);
> >
> 


From ddadacha at redhat.com  Tue Apr  3 12:13:17 2012
From: ddadacha at redhat.com (Danesh Dadachanji)
Date: Tue, 03 Apr 2012 15:13:17 -0400
Subject: [RFC][icedtea-web] Use IcedTea as the vendor for all JNLPs in
	test suite
In-Reply-To: <4F7B3DD8.80904@redhat.com>
References: <4F7B3DD8.80904@redhat.com>
Message-ID: <4F7B4BCD.6090803@redhat.com>

On 03/04/12 02:13 PM, Danesh Dadachanji wrote:
> Hi,
>
> Many of the JNLPs in the test suite have various vendors (for no particular reason). For the community's sake, I'd like to replace all
> the ones under tests/jnlp_tests/ with IcedTea. I'm avoiding touching the unit test ones because I'm not 100% sure the vendor's being
> specified explicitly to be tested.
>
> This command should do the trick:
> $ find ./icedtea-web/tests/jnlp_tests/ -name *\.jnlp -exec sed -ie 's/<vendor>[A-Za-z0-9 ]*<\/vendor>/<vendor>IcedTea<\/vendor>/g' {} \;
>
> The attached patch has the result, the above worked as expected.
>

Omair pointed out that I might as well change the homepage URL too, we decided on this page[1] on IRC. I think the testing subheading 
is a good location at which to point, thanks to Jiri for thinking of it!

Command was:

$ find ./icedtea-web/tests/jnlp_tests/ -name *\.jnlp -exec sed -ie 's/<homepage href=".*"\/>/<homepage 
href="http:\/\/icedtea.classpath.org\/wiki\/IcedTea-Web#Testing_IcedTea-Web"\/>/' {} \;

Any other comments?

> Okay to push to HEAD?


Cheers,
Danesh

[1] http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Websda


From ddadacha at redhat.com  Tue Apr  3 12:13:28 2012
From: ddadacha at redhat.com (Danesh Dadachanji)
Date: Tue, 03 Apr 2012 15:13:28 -0400
Subject: [RFC][icedtea-web] Use IcedTea as the vendor for all JNLPs in
	test suite
In-Reply-To: <4F7B3DD8.80904@redhat.com>
References: <4F7B3DD8.80904@redhat.com>
Message-ID: <4F7B4BD8.3010701@redhat.com>

On 03/04/12 02:13 PM, Danesh Dadachanji wrote:
> Hi,
>
> Many of the JNLPs in the test suite have various vendors (for no particular reason). For the community's sake, I'd like to replace all
> the ones under tests/jnlp_tests/ with IcedTea. I'm avoiding touching the unit test ones because I'm not 100% sure the vendor's being
> specified explicitly to be tested.
>
> This command should do the trick:
> $ find ./icedtea-web/tests/jnlp_tests/ -name *\.jnlp -exec sed -ie 's/<vendor>[A-Za-z0-9 ]*<\/vendor>/<vendor>IcedTea<\/vendor>/g' {} \;
>
> The attached patch has the result, the above worked as expected.
>

Omair pointed out that I might as well change the homepage URL too, we decided on this page[1] on IRC. I think the testing subheading 
is a good location at which to point, thanks to Jiri for thinking of it!

Command was:

$ find ./icedtea-web/tests/jnlp_tests/ -name *\.jnlp -exec sed -ie 's/<homepage href=".*"\/>/<homepage 
href="http:\/\/icedtea.classpath.org\/wiki\/IcedTea-Web#Testing_IcedTea-Web"\/>/' {} \;

Any other comments?

> Okay to push to HEAD?


Cheers,
Danesh

[1] http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Websda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: replace-vendor-with-icedtea-02.patch
Type: text/x-patch
Size: 47312 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120403/346d117b/replace-vendor-with-icedtea-02.patch 

From omajid at redhat.com  Tue Apr  3 12:27:13 2012
From: omajid at redhat.com (Omair Majid)
Date: Tue, 03 Apr 2012 15:27:13 -0400
Subject: [RFC][icedtea-web] Use IcedTea as the vendor for all JNLPs in
	test suite
In-Reply-To: <4F7B4BD8.3010701@redhat.com>
References: <4F7B3DD8.80904@redhat.com> <4F7B4BD8.3010701@redhat.com>
Message-ID: <4F7B4F11.3070306@redhat.com>

On 04/03/2012 03:13 PM, Danesh Dadachanji wrote:
> On 03/04/12 02:13 PM, Danesh Dadachanji wrote:
>> Hi,
>>
>> Many of the JNLPs in the test suite have various vendors (for no
>> particular reason). For the community's sake, I'd like to replace all
>> the ones under tests/jnlp_tests/ with IcedTea. I'm avoiding touching
>> the unit test ones because I'm not 100% sure the vendor's being
>> specified explicitly to be tested.
>>
>> This command should do the trick:
>> $ find ./icedtea-web/tests/jnlp_tests/ -name *\.jnlp -exec sed -ie
>> 's/<vendor>[A-Za-z0-9 ]*<\/vendor>/<vendor>IcedTea<\/vendor>/g' {} \;
>>
>> The attached patch has the result, the above worked as expected.
>>
> 
> Omair pointed out that I might as well change the homepage URL too, we
> decided on this page[1] on IRC. I think the testing subheading is a good
> location at which to point, thanks to Jiri for thinking of it!
> 
> Command was:
> 
> $ find ./icedtea-web/tests/jnlp_tests/ -name *\.jnlp -exec sed -ie
> 's/<homepage href=".*"\/>/<homepage
> href="http:\/\/icedtea.classpath.org\/wiki\/IcedTea-Web#Testing_IcedTea-Web"\/>/'
> {} \;
> 
> Any other comments?
> 

Looks okay to me. Just one question: are there any tests that check for
the value of homepage or vendor?

Thanks,
Omair


From omajid at redhat.com  Tue Apr  3 12:57:45 2012
From: omajid at redhat.com (Omair Majid)
Date: Tue, 03 Apr 2012 15:57:45 -0400
Subject: [RFC][icedtea-web] Use IcedTea as the vendor for all JNLPs in
	test suite
In-Reply-To: <4F7B5326.2050005@redhat.com>
References: <4F7B3DD8.80904@redhat.com> <4F7B4BD8.3010701@redhat.com>
	<4F7B4F11.3070306@redhat.com> <4F7B5326.2050005@redhat.com>
Message-ID: <4F7B5639.1050600@redhat.com>

On 04/03/2012 03:44 PM, Danesh Dadachanji wrote:
> The unit tests on the other hand are something I'd have to look at more
> closely..

But since those are self contained and located in a different directory
(tests/netx/unit), they really shouldn't be affected by these changes.

Cheers,
Omair



From ddadacha at redhat.com  Tue Apr  3 13:01:58 2012
From: ddadacha at redhat.com (Danesh Dadachanji)
Date: Tue, 03 Apr 2012 16:01:58 -0400
Subject: [RFC][icedtea-web] Use IcedTea as the vendor for all JNLPs in
	test suite
In-Reply-To: <4F7B5639.1050600@redhat.com>
References: <4F7B3DD8.80904@redhat.com> <4F7B4BD8.3010701@redhat.com>
	<4F7B4F11.3070306@redhat.com> <4F7B5326.2050005@redhat.com>
	<4F7B5639.1050600@redhat.com>
Message-ID: <4F7B5736.70408@redhat.com>

On 03/04/12 03:57 PM, Omair Majid wrote:
> On 04/03/2012 03:44 PM, Danesh Dadachanji wrote:
>> The unit tests on the other hand are something I'd have to look at more
>> closely..
>
> But since those are self contained and located in a different directory
> (tests/netx/unit), they really shouldn't be affected by these changes.
>

Right, I meant that if we wanted to change those, I would have to look more closely at each one.

In the mean time, can I push these to HEAD?

Cheers,
Danesh


From omajid at redhat.com  Tue Apr  3 13:02:26 2012
From: omajid at redhat.com (Omair Majid)
Date: Tue, 03 Apr 2012 16:02:26 -0400
Subject: [RFC][icedtea-web] Use IcedTea as the vendor for all JNLPs in
	test suite
In-Reply-To: <4F7B5736.70408@redhat.com>
References: <4F7B3DD8.80904@redhat.com> <4F7B4BD8.3010701@redhat.com>
	<4F7B4F11.3070306@redhat.com> <4F7B5326.2050005@redhat.com>
	<4F7B5639.1050600@redhat.com> <4F7B5736.70408@redhat.com>
Message-ID: <4F7B5752.70409@redhat.com>

On 04/03/2012 04:01 PM, Danesh Dadachanji wrote:
> On 03/04/12 03:57 PM, Omair Majid wrote:
>> On 04/03/2012 03:44 PM, Danesh Dadachanji wrote:
>>> The unit tests on the other hand are something I'd have to look at more
>>> closely..
>>
>> But since those are self contained and located in a different directory
>> (tests/netx/unit), they really shouldn't be affected by these changes.
>>
> 
> Right, I meant that if we wanted to change those, I would have to look
> more closely at each one.

Oh, I misunderstood.

> In the mean time, can I push these to HEAD?

Yes, please.

Cheers,
Omair


From ddadacha at icedtea.classpath.org  Tue Apr  3 13:06:28 2012
From: ddadacha at icedtea.classpath.org (ddadacha at icedtea.classpath.org)
Date: Tue, 03 Apr 2012 20:06:28 +0000
Subject: /hg/icedtea-web: Changed the vendor and homepage tags of all JNL...
Message-ID: <hg.f85f7c359b71.1333483588.8643924302249223276@icedtea.classpath.org>

changeset f85f7c359b71 in /hg/icedtea-web
details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=f85f7c359b71
author: Danesh Dadachanji <ddadacha at redhat.com>
date: Tue Apr 03 16:04:55 2012 -0400

	Changed the vendor and homepage tags of all JNLPs in the testsuite to point to IcedTea.


diffstat:

 ChangeLog                                                                                             |  62 ++++++++++
 tests/jnlp_tests/signed/AccessClassInPackageSigned/resources/AccessClassInPackageSignedJAVAXJNLP.jnlp |   4 +-
 tests/jnlp_tests/signed/AccessClassInPackageSigned/resources/AccessClassInPackageSignedNETSF.jnlp     |   4 +-
 tests/jnlp_tests/signed/AccessClassInPackageSigned/resources/AccessClassInPackageSignedSELF.jnlp      |   4 +-
 tests/jnlp_tests/signed/AccessClassInPackageSigned/resources/AccessClassInPackageSignedSUNSEC.jnlp    |   4 +-
 tests/jnlp_tests/signed/CacheReproducer/resources/CacheReproducer1.jnlp                               |   2 +-
 tests/jnlp_tests/signed/CacheReproducer/resources/CacheReproducer1_1.jnlp                             |   2 +-
 tests/jnlp_tests/signed/CacheReproducer/resources/CacheReproducer2.jnlp                               |   2 +-
 tests/jnlp_tests/signed/CacheReproducer/resources/CacheReproducer2_1.jnlp                             |   2 +-
 tests/jnlp_tests/signed/MissingJar/resources/MissingJar.jnlp                                          |   2 +-
 tests/jnlp_tests/signed/MissingJar/resources/MissingJar2.jnlp                                         |   2 +-
 tests/jnlp_tests/signed/MissingJar/resources/MissingJar3.jnlp                                         |   2 +-
 tests/jnlp_tests/signed/MissingJar/resources/MissingJar4.jnlp                                         |   2 +-
 tests/jnlp_tests/signed/ReadPropertiesBySignedHack/resources/ReadPropertiesBySignedHack.jnlp          |   2 +-
 tests/jnlp_tests/signed/ReadPropertiesSigned/resources/ReadPropertiesSigned1.jnlp                     |   2 +-
 tests/jnlp_tests/signed/ReadPropertiesSigned/resources/ReadPropertiesSigned2.jnlp                     |   2 +-
 tests/jnlp_tests/signed/SimpletestSigned1/resources/SimpletestSigned1.jnlp                            |   4 +-
 tests/jnlp_tests/simple/AccessClassInPackage/resources/AccessClassInPackageJAVAXJNLP.jnlp             |   4 +-
 tests/jnlp_tests/simple/AccessClassInPackage/resources/AccessClassInPackageNETSF.jnlp                 |   4 +-
 tests/jnlp_tests/simple/AccessClassInPackage/resources/AccessClassInPackageSELF.jnlp                  |   4 +-
 tests/jnlp_tests/simple/AccessClassInPackage/resources/AccessClassInPackageSUNSEC.jnlp                |   4 +-
 tests/jnlp_tests/simple/AddShutdownHook/resources/AddShutdownHook.jnlp                                |   2 +-
 tests/jnlp_tests/simple/AllStackTraces/resources/AllStackTraces.jnlp                                  |   2 +-
 tests/jnlp_tests/simple/AppletTest/resources/AppletTest.jnlp                                          |   4 +-
 tests/jnlp_tests/simple/CheckServices/resources/CheckServices.jnlp                                    |   2 +-
 tests/jnlp_tests/simple/CreateClassLoader/resources/CreateClassLoader.jnlp                            |   2 +-
 tests/jnlp_tests/simple/InformationTitleVendorParser/resources/TitleParser.jnlp                       |   2 +-
 tests/jnlp_tests/simple/InformationTitleVendorParser/resources/TitleVendorParser.jnlp                 |   2 +-
 tests/jnlp_tests/simple/InformationTitleVendorParser/resources/VendorParser.jnlp                      |   2 +-
 tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1main2mainAppDesc.jnlp                 |   4 +-
 tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1main2mainNoAppDesc.jnlp               |   4 +-
 tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1main2nothingNoAppDesc.jnlp            |   4 +-
 tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1mainHaveAppDesc.jnlp                  |   4 +-
 tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1mainNoAppDesc.jnlp                    |   4 +-
 tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1noAppDesc.jnlp                        |   4 +-
 tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1noAppDescAtAll.jnlp                   |   4 +-
 tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1nothing2nothingAppDesc.jnlp           |   4 +-
 tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1nothing2nothingNoAppDesc.jnlp         |   4 +-
 tests/jnlp_tests/simple/ReadEnvironment/resources/ReadEnvironment.jnlp                                |   2 +-
 tests/jnlp_tests/simple/ReadProperties/resources/ReadProperties1.jnlp                                 |   2 +-
 tests/jnlp_tests/simple/ReadProperties/resources/ReadProperties2.jnlp                                 |   2 +-
 tests/jnlp_tests/simple/RedirectStreams/resources/RedirectStreams.jnlp                                |   2 +-
 tests/jnlp_tests/simple/ReplaceSecurityManager/resources/ReplaceSecurityManager.jnlp                  |   2 +-
 tests/jnlp_tests/simple/SetContextClassLoader/resources/SetContextClassLoader.jnlp                    |   2 +-
 tests/jnlp_tests/simple/Spaces can be everywhere/resources/Spaces can be everywhere1.jnlp             |   4 +-
 tests/jnlp_tests/simple/Spaces can be everywhere/resources/Spaces can be everywhere2.jnlp             |   4 +-
 tests/jnlp_tests/simple/Spaces can be everywhere/resources/SpacesCanBeEverywhere1.jnlp                |   4 +-
 tests/jnlp_tests/simple/deadlocktest/resources/deadlocktest.jnlp                                      |   4 +-
 tests/jnlp_tests/simple/deadlocktest/resources/deadlocktest_1.jnlp                                    |   4 +-
 tests/jnlp_tests/simple/simpletest1/resources/simpletest1.jnlp                                        |   4 +-
 tests/jnlp_tests/simple/simpletest1/resources/simpletestCustomSplash.jnlp                             |   4 +-
 tests/jnlp_tests/simple/simpletest1/resources/simpletestMegaSlow.jnlp                                 |   4 +-
 tests/jnlp_tests/simple/simpletest1/resources/simpletestSlow.jnlp                                     |   4 +-
 tests/jnlp_tests/simple/simpletest1/resources/simpletestSlowBrokenCustomSplash.jnlp                   |   4 +-
 tests/jnlp_tests/simple/simpletest1/resources/simpletestSlowSlowCustomSplash.jnlp                     |   4 +-
 tests/jnlp_tests/simple/simpletest2/resources/simpletest2.jnlp                                        |   4 +-
 56 files changed, 148 insertions(+), 86 deletions(-)

diffs (truncated from 791 to 500 lines):

diff -r 60a2cbc4e542 -r f85f7c359b71 ChangeLog
--- a/ChangeLog	Tue Apr 03 12:13:24 2012 -0400
+++ b/ChangeLog	Tue Apr 03 16:04:55 2012 -0400
@@ -1,3 +1,65 @@
+2012-04-03  Danesh Dadachanji  <ddadacha at redhat.com>
+
+	Change all vendors in JNLP test suite to IcedTea and homepage href's to
+	a link to IcedTea-Web's wiki page.
+	* tests/jnlp_tests/signed/AccessClassInPackageSigned/resources/AccessClassInPackageSignedJAVAXJNLP.jnlp
+	* tests/jnlp_tests/signed/AccessClassInPackageSigned/resources/AccessClassInPackageSignedNETSF.jnlp
+	* tests/jnlp_tests/signed/AccessClassInPackageSigned/resources/AccessClassInPackageSignedSELF.jnlp
+	* tests/jnlp_tests/signed/AccessClassInPackageSigned/resources/AccessClassInPackageSignedSUNSEC.jnlp
+	* tests/jnlp_tests/signed/CacheReproducer/resources/CacheReproducer1.jnlp
+	* tests/jnlp_tests/signed/CacheReproducer/resources/CacheReproducer1_1.jnlp
+	* tests/jnlp_tests/signed/CacheReproducer/resources/CacheReproducer2.jnlp
+	* tests/jnlp_tests/signed/CacheReproducer/resources/CacheReproducer2_1.jnlp
+	* tests/jnlp_tests/signed/MissingJar/resources/MissingJar.jnlp
+	* tests/jnlp_tests/signed/MissingJar/resources/MissingJar2.jnlp
+	* tests/jnlp_tests/signed/MissingJar/resources/MissingJar3.jnlp
+	* tests/jnlp_tests/signed/MissingJar/resources/MissingJar4.jnlp
+	* tests/jnlp_tests/signed/ReadPropertiesBySignedHack/resources/ReadPropertiesBySignedHack.jnlp
+	* tests/jnlp_tests/signed/ReadPropertiesSigned/resources/ReadPropertiesSigned1.jnlp
+	* tests/jnlp_tests/signed/ReadPropertiesSigned/resources/ReadPropertiesSigned2.jnlp
+	* tests/jnlp_tests/signed/SimpletestSigned1/resources/SimpletestSigned1.jnlp
+	* tests/jnlp_tests/simple/AccessClassInPackage/resources/AccessClassInPackageJAVAXJNLP.jnlp
+	* tests/jnlp_tests/simple/AccessClassInPackage/resources/AccessClassInPackageNETSF.jnlp
+	* tests/jnlp_tests/simple/AccessClassInPackage/resources/AccessClassInPackageSELF.jnlp
+	* tests/jnlp_tests/simple/AccessClassInPackage/resources/AccessClassInPackageSUNSEC.jnlp
+	* tests/jnlp_tests/simple/AddShutdownHook/resources/AddShutdownHook.jnlp
+	* tests/jnlp_tests/simple/AllStackTraces/resources/AllStackTraces.jnlp
+	* tests/jnlp_tests/simple/AppletTest/resources/AppletTest.jnlp
+	* tests/jnlp_tests/simple/CheckServices/resources/CheckServices.jnlp
+	* tests/jnlp_tests/simple/CreateClassLoader/resources/CreateClassLoader.jnlp
+	* tests/jnlp_tests/simple/InformationTitleVendorParser/resources/TitleParser.jnlp
+	* tests/jnlp_tests/simple/InformationTitleVendorParser/resources/TitleVendorParser.jnlp
+	* tests/jnlp_tests/simple/InformationTitleVendorParser/resources/VendorParser.jnlp
+	* tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1main2mainAppDesc.jnlp
+	* tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1main2mainNoAppDesc.jnlp
+	* tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1main2nothingNoAppDesc.jnlp
+	* tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1mainHaveAppDesc.jnlp
+	* tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1mainNoAppDesc.jnlp
+	* tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1noAppDesc.jnlp
+	* tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1noAppDescAtAll.jnlp
+	* tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1nothing2nothingAppDesc.jnlp
+	* tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1nothing2nothingNoAppDesc.jnlp
+	* tests/jnlp_tests/simple/ReadEnvironment/resources/ReadEnvironment.jnlp
+	* tests/jnlp_tests/simple/ReadProperties/resources/ReadProperties1.jnlp
+	* tests/jnlp_tests/simple/ReadProperties/resources/ReadProperties2.jnlp
+	* tests/jnlp_tests/simple/RedirectStreams/resources/RedirectStreams.jnlp
+	* tests/jnlp_tests/simple/ReplaceSecurityManager/resources/ReplaceSecurityManager.jnlp
+	* tests/jnlp_tests/simple/SetContextClassLoader/resources/SetContextClassLoader.jnlp
+	* tests/jnlp_tests/simple/Spaces can be everywhere/resources/Spaces can be everywhere1.jnlp
+	* tests/jnlp_tests/simple/Spaces can be everywhere/resources/Spaces can be everywhere2.jnlp
+	* tests/jnlp_tests/simple/Spaces can be everywhere/resources/SpacesCanBeEverywhere1.jnlp
+	* tests/jnlp_tests/simple/deadlocktest/resources/deadlocktest.jnlp
+	* tests/jnlp_tests/simple/deadlocktest/resources/deadlocktest_1.jnlp
+	* tests/jnlp_tests/simple/simpletest1/resources/simpletest1.jnlp
+	* tests/jnlp_tests/simple/simpletest1/resources/simpletestCustomSplash.jnlp
+	* tests/jnlp_tests/simple/simpletest1/resources/simpletestMegaSlow.jnlp
+	* tests/jnlp_tests/simple/simpletest1/resources/simpletestSlow.jnlp
+	* tests/jnlp_tests/simple/simpletest1/resources/simpletestSlowBrokenCustomSplash.jnlp
+	* tests/jnlp_tests/simple/simpletest1/resources/simpletestSlowSlowCustomSplash.jnlp
+	* tests/jnlp_tests/simple/simpletest2/resources/simpletest2.jnlp:
+	Replaced the specified vendor with IcedTea and homepage with a link to
+	IcedTea-Web's wiki.
+
 2012-04-03  Omair Majid  <omajid at redhat.com>
 
 	* netx/net/sourceforge/jnlp/runtime/pac-funcs.js: Replace incorrect use of
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/signed/AccessClassInPackageSigned/resources/AccessClassInPackageSignedJAVAXJNLP.jnlp
--- a/tests/jnlp_tests/signed/AccessClassInPackageSigned/resources/AccessClassInPackageSignedJAVAXJNLP.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/signed/AccessClassInPackageSigned/resources/AccessClassInPackageSignedJAVAXJNLP.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -41,8 +41,8 @@
       href="AccessClassInPackageJAVAXJNLP.jnlp">
    <information> 
       <title>Test accessClassInPackage signed</title>
-      <vendor>NetX</vendor>
-      <homepage href="http://jnlp.sourceforge.net/netx/"/>
+      <vendor>IcedTea</vendor>
+      <homepage href="http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Web"/>
       <description>testing access to some javax.jnlp.* package by signed app</description>
    </information> 
    <resources>
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/signed/AccessClassInPackageSigned/resources/AccessClassInPackageSignedNETSF.jnlp
--- a/tests/jnlp_tests/signed/AccessClassInPackageSigned/resources/AccessClassInPackageSignedNETSF.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/signed/AccessClassInPackageSigned/resources/AccessClassInPackageSignedNETSF.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -41,8 +41,8 @@
       href="AccessClassInPackageSignedNETSF.jnlp">
    <information> 
       <title>Test accessClassInPackage  by signed app</title>
-      <vendor>NetX</vendor>
-      <homepage href="http://jnlp.sourceforge.net/netx/"/>
+      <vendor>IcedTea</vendor>
+      <homepage href="http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Web"/>
       <description>testing access to net.sourceforge.* package  by signed app</description>
    </information> 
    <resources>
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/signed/AccessClassInPackageSigned/resources/AccessClassInPackageSignedSELF.jnlp
--- a/tests/jnlp_tests/signed/AccessClassInPackageSigned/resources/AccessClassInPackageSignedSELF.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/signed/AccessClassInPackageSigned/resources/AccessClassInPackageSignedSELF.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -41,8 +41,8 @@
       href="AccessClassInPackageSignedSELF.jnlp">
    <information> 
       <title>Test accessClassInPackage by signed app</title>
-      <vendor>NetX</vendor>
-      <homepage href="http://jnlp.sourceforge.net/netx/"/>
+      <vendor>IcedTea</vendor>
+      <homepage href="http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Web"/>
       <description>testing aaccess to package's internal class by signed app</description>
    </information> 
    <resources>
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/signed/AccessClassInPackageSigned/resources/AccessClassInPackageSignedSUNSEC.jnlp
--- a/tests/jnlp_tests/signed/AccessClassInPackageSigned/resources/AccessClassInPackageSignedSUNSEC.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/signed/AccessClassInPackageSigned/resources/AccessClassInPackageSignedSUNSEC.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -41,8 +41,8 @@
       href="AccessClassInPackageSignedSUNSEC.jnlp">
    <information> 
       <title>Test accessClassInPackage by signed app</title>
-      <vendor>NetX</vendor>
-      <homepage href="http://jnlp.sourceforge.net/netx/"/>
+      <vendor>IcedTea</vendor>
+      <homepage href="http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Web"/>
     <description>testing access to sun.security.* package by signed app</description>
    </information> 
    <resources>
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/signed/CacheReproducer/resources/CacheReproducer1.jnlp
--- a/tests/jnlp_tests/signed/CacheReproducer/resources/CacheReproducer1.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/signed/CacheReproducer/resources/CacheReproducer1.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -4,7 +4,7 @@
       href="CacheReproducer1.jnlp">
     <information>
         <title>Just prints out "Good simple javaws exapmle" using reflection call from CacheReproducer.jar SimpletestSigned1.jar</title>
-        <vendor>Red Hat</vendor>
+        <vendor>IcedTea</vendor>
     </information>
     <resources>
         <jar href="CacheReproducer.jar" main="true"/>
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/signed/CacheReproducer/resources/CacheReproducer1_1.jnlp
--- a/tests/jnlp_tests/signed/CacheReproducer/resources/CacheReproducer1_1.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/signed/CacheReproducer/resources/CacheReproducer1_1.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -4,7 +4,7 @@
       href="CacheReproducer1_1.jnlp">
     <information>
         <title>Just prints out "Good simple javaws exapmle" using reflection call from CacheReproducer.jar SimpletestSigned1.jar</title>
-        <vendor>Red Hat</vendor>
+        <vendor>IcedTea</vendor>
     </information>
     <resources>
         <jar href="CacheReproducer.jar" main="true"/>
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/signed/CacheReproducer/resources/CacheReproducer2.jnlp
--- a/tests/jnlp_tests/signed/CacheReproducer/resources/CacheReproducer2.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/signed/CacheReproducer/resources/CacheReproducer2.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -4,7 +4,7 @@
       href="CacheReproducer2.jnlp">
     <information>
         <title>Just prints out "Good simple javaws exapmle" using reflection call from CacheReproducer.jar SimpletestSigned1.jar</title>
-        <vendor>Red Hat</vendor>
+        <vendor>IcedTea</vendor>
     </information>
     <resources>
         <jar href="SimpletestSigned1.jar" main="false" download="eager"/>
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/signed/CacheReproducer/resources/CacheReproducer2_1.jnlp
--- a/tests/jnlp_tests/signed/CacheReproducer/resources/CacheReproducer2_1.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/signed/CacheReproducer/resources/CacheReproducer2_1.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -4,7 +4,7 @@
       href="CacheReproducer2_1.jnlp">
     <information>
         <title>Just prints out "Good simple javaws exapmle" using reflection call from CacheReproducer.jar SimpletestSigned1.jar</title>
-        <vendor>Red Hat</vendor>
+        <vendor>IcedTea</vendor>
     </information>
     <resources>
         <jar href="SimpletestSigned1.jar" main="false" download="lazy"/>
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/signed/MissingJar/resources/MissingJar.jnlp
--- a/tests/jnlp_tests/signed/MissingJar/resources/MissingJar.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/signed/MissingJar/resources/MissingJar.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -4,7 +4,7 @@
       href="MissingJar.jnlp">
    <information> 
       <title>test MissingJar</title> 
-      <vendor>Red Hat</vendor>
+      <vendor>IcedTea</vendor>
    </information> 
    <resources>
       <!-- MissingJar is name of reproducer and of main jar,
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/signed/MissingJar/resources/MissingJar2.jnlp
--- a/tests/jnlp_tests/signed/MissingJar/resources/MissingJar2.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/signed/MissingJar/resources/MissingJar2.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -4,7 +4,7 @@
       href="MissingJar2.jnlp">
    <information> 
       <title>test MissingJar</title> 
-      <vendor>Red Hat</vendor>
+      <vendor>IcedTea</vendor>
    </information> 
    <resources>
       <jar href="ThisOneIsMissing.jar"  />
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/signed/MissingJar/resources/MissingJar3.jnlp
--- a/tests/jnlp_tests/signed/MissingJar/resources/MissingJar3.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/signed/MissingJar/resources/MissingJar3.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -4,7 +4,7 @@
       href="MissingJar3.jnlp">
    <information> 
       <title>test MissingJar</title> 
-      <vendor>Red Hat</vendor>
+      <vendor>IcedTea</vendor>
    </information> 
    <resources>
       <!-- MissingJar is name of reproducer and of main jar,
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/signed/MissingJar/resources/MissingJar4.jnlp
--- a/tests/jnlp_tests/signed/MissingJar/resources/MissingJar4.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/signed/MissingJar/resources/MissingJar4.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -4,7 +4,7 @@
       href="MissingJar4.jnlp">
    <information> 
       <title>test MissingJar</title> 
-      <vendor>Red Hat</vendor>
+      <vendor>IcedTea</vendor>
    </information> 
    <resources>
       <jar href="ThisOneIsMissing.jar"  />
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/signed/ReadPropertiesBySignedHack/resources/ReadPropertiesBySignedHack.jnlp
--- a/tests/jnlp_tests/signed/ReadPropertiesBySignedHack/resources/ReadPropertiesBySignedHack.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/signed/ReadPropertiesBySignedHack/resources/ReadPropertiesBySignedHack.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -4,7 +4,7 @@
       href="ReadPropertiesBySignedHack.jnlp">
     <information>
         <title>read properties using System.getenv()</title>
-        <vendor>Red Hat</vendor>
+        <vendor>IcedTea</vendor>
     </information>
     <resources>
         <jar href="ReadPropertiesBySignedHack.jar" main="true"/>
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/signed/ReadPropertiesSigned/resources/ReadPropertiesSigned1.jnlp
--- a/tests/jnlp_tests/signed/ReadPropertiesSigned/resources/ReadPropertiesSigned1.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/signed/ReadPropertiesSigned/resources/ReadPropertiesSigned1.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -4,7 +4,7 @@
       href="ReadPropertiesSigned1.jnlp">
     <information>
         <title>read properties using System.getenv()</title>
-        <vendor>Red Hat</vendor>
+        <vendor>IcedTea</vendor>
     </information>
     <resources>
         <jar href="ReadPropertiesSigned.jar" main="true"/>
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/signed/ReadPropertiesSigned/resources/ReadPropertiesSigned2.jnlp
--- a/tests/jnlp_tests/signed/ReadPropertiesSigned/resources/ReadPropertiesSigned2.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/signed/ReadPropertiesSigned/resources/ReadPropertiesSigned2.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -4,7 +4,7 @@
       href="ReadPropertiesSigned2.jnlp">
     <information>
         <title>read properties using System.getenv()</title>
-        <vendor>Red Hat</vendor>
+        <vendor>IcedTea</vendor>
     </information>
     <resources>
         <jar href="ReadPropertiesSigned.jar" main="true"/>
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/signed/SimpletestSigned1/resources/SimpletestSigned1.jnlp
--- a/tests/jnlp_tests/signed/SimpletestSigned1/resources/SimpletestSigned1.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/signed/SimpletestSigned1/resources/SimpletestSigned1.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -39,8 +39,8 @@
 <jnlp spec="1.0" href="SimpletestSigned1.jnlp" codebase=".">
   <information>
     <title>simpletest1</title>
-    <vendor>NetX</vendor>
-    <homepage href="http://jnlp.sourceforge.net/netx/"/>
+    <vendor>IcedTea</vendor>
+    <homepage href="http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Web"/>
     <description>simpletest1</description>
     <offline/>
   </information>
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/simple/AccessClassInPackage/resources/AccessClassInPackageJAVAXJNLP.jnlp
--- a/tests/jnlp_tests/simple/AccessClassInPackage/resources/AccessClassInPackageJAVAXJNLP.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/simple/AccessClassInPackage/resources/AccessClassInPackageJAVAXJNLP.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -41,8 +41,8 @@
       href="AccessClassInPackageJAVAXJNLP.jnlp">
    <information> 
       <title>Test accessClassInPackage</title>
-      <vendor>NetX</vendor>
-      <homepage href="http://jnlp.sourceforge.net/netx/"/>
+      <vendor>IcedTea</vendor>
+      <homepage href="http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Web"/>
       <description>testing access to some javax.jnlp.* package</description>
    </information> 
    <resources>
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/simple/AccessClassInPackage/resources/AccessClassInPackageNETSF.jnlp
--- a/tests/jnlp_tests/simple/AccessClassInPackage/resources/AccessClassInPackageNETSF.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/simple/AccessClassInPackage/resources/AccessClassInPackageNETSF.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -41,8 +41,8 @@
       href="AccessClassInPackageNETSF.jnlp">
    <information> 
       <title>Test accessClassInPackage</title>
-      <vendor>NetX</vendor>
-      <homepage href="http://jnlp.sourceforge.net/netx/"/>
+      <vendor>IcedTea</vendor>
+      <homepage href="http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Web"/>
       <description>testing access to net.sourceforge.* package</description>
    </information> 
    <resources>
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/simple/AccessClassInPackage/resources/AccessClassInPackageSELF.jnlp
--- a/tests/jnlp_tests/simple/AccessClassInPackage/resources/AccessClassInPackageSELF.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/simple/AccessClassInPackage/resources/AccessClassInPackageSELF.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -41,8 +41,8 @@
       href="AccessClassInPackageSELF.jnlp">
    <information> 
       <title>Test accessClassInPackage</title>
-      <vendor>NetX</vendor>
-      <homepage href="http://jnlp.sourceforge.net/netx/"/>
+      <vendor>IcedTea</vendor>
+      <homepage href="http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Web"/>
       <description>testing aaccess to package's internal class</description>
    </information> 
    <resources>
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/simple/AccessClassInPackage/resources/AccessClassInPackageSUNSEC.jnlp
--- a/tests/jnlp_tests/simple/AccessClassInPackage/resources/AccessClassInPackageSUNSEC.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/simple/AccessClassInPackage/resources/AccessClassInPackageSUNSEC.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -41,8 +41,8 @@
       href="AccessClassInPackageSUNSEC.jnlp">
    <information> 
       <title>Test accessClassInPackage</title>
-      <vendor>NetX</vendor>
-      <homepage href="http://jnlp.sourceforge.net/netx/"/>
+      <vendor>IcedTea</vendor>
+      <homepage href="http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Web"/>
     <description>testing access to sun.security.* package</description>
    </information> 
    <resources>
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/simple/AddShutdownHook/resources/AddShutdownHook.jnlp
--- a/tests/jnlp_tests/simple/AddShutdownHook/resources/AddShutdownHook.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/simple/AddShutdownHook/resources/AddShutdownHook.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -4,7 +4,7 @@
       href="AddShutdownHook.jnlp">
    <information> 
       <title>test adding shutdown hooks</title> 
-      <vendor>Red Hat</vendor>
+      <vendor>IcedTea</vendor>
    </information> 
    <resources>
       <jar href="AddShutdownHook.jar" main="true" download="eager"/>
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/simple/AllStackTraces/resources/AllStackTraces.jnlp
--- a/tests/jnlp_tests/simple/AllStackTraces/resources/AllStackTraces.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/simple/AllStackTraces/resources/AllStackTraces.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -4,7 +4,7 @@
       href="AllStackTraces.jnlp">
    <information> 
       <title>Test Thread.getAllStackTraces</title> 
-      <vendor>Red Hat</vendor>
+      <vendor>IcedTea</vendor>
    </information> 
    <resources>
       <jar href="AllStackTraces.jar" main="true" download="eager"/>
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/simple/AppletTest/resources/AppletTest.jnlp
--- a/tests/jnlp_tests/simple/AppletTest/resources/AppletTest.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/simple/AppletTest/resources/AppletTest.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -39,8 +39,8 @@
 <jnlp spec="1.0" href="AppletTest.jnlp" codebase=".">
     <information>
         <title>AppletTest</title>
-        <vendor>NetX</vendor>
-        <homepage href="http://jnlp.sourceforge.net/netx/"/>
+        <vendor>IcedTea</vendor>
+        <homepage href="http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Web"/>
         <description>AppletTest</description>
         <offline/>
     </information>
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/simple/CheckServices/resources/CheckServices.jnlp
--- a/tests/jnlp_tests/simple/CheckServices/resources/CheckServices.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/simple/CheckServices/resources/CheckServices.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -40,7 +40,7 @@
     <information>
         <title>CheckServices</title>
         <vendor>IcedTea</vendor>
-        <homepage href="http://jnlp.sourceforge.net/netx/"/>
+        <homepage href="http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Web"/>
         <description>CheckServices</description>
         <offline/>
     </information>
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/simple/CreateClassLoader/resources/CreateClassLoader.jnlp
--- a/tests/jnlp_tests/simple/CreateClassLoader/resources/CreateClassLoader.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/simple/CreateClassLoader/resources/CreateClassLoader.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -4,7 +4,7 @@
       href="CreateClassLoader.jnlp">
     <information>
         <title>set context classloader</title>
-        <vendor>Red Hat</vendor>
+        <vendor>IcedTea</vendor>
     </information>
     <resources>
         <jar href="CreateClassLoader.jar" main="true" download="eager"/>
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/simple/InformationTitleVendorParser/resources/TitleParser.jnlp
--- a/tests/jnlp_tests/simple/InformationTitleVendorParser/resources/TitleParser.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/simple/InformationTitleVendorParser/resources/TitleParser.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -39,7 +39,7 @@
 <jnlp spec="1.0" href="TitleParser.jnlp" codebase=".">
   <information>
     <vendor>IcedTea</vendor>
-    <homepage href="http://jnlp.sourceforge.net/netx/"/>
+    <homepage href="http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Web"/>
     <description>Title tag missing</description>
     <offline/>
   </information>
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/simple/InformationTitleVendorParser/resources/TitleVendorParser.jnlp
--- a/tests/jnlp_tests/simple/InformationTitleVendorParser/resources/TitleVendorParser.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/simple/InformationTitleVendorParser/resources/TitleVendorParser.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -38,7 +38,7 @@
 <?xml version="1.0" encoding="utf-8"?>
 <jnlp spec="1.0" href="TitleVendorParser.jnlp" codebase=".">
   <information>
-    <homepage href="http://jnlp.sourceforge.net/netx/"/>
+    <homepage href="http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Web"/>
     <description>Title/Vendor tags missing</description>
     <offline/>
   </information>
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/simple/InformationTitleVendorParser/resources/VendorParser.jnlp
--- a/tests/jnlp_tests/simple/InformationTitleVendorParser/resources/VendorParser.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/simple/InformationTitleVendorParser/resources/VendorParser.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -39,7 +39,7 @@
 <jnlp spec="1.0" href="VendorParser.jnlp" codebase=".">
   <information>
     <title>VendorParser</title>
-    <homepage href="http://jnlp.sourceforge.net/netx/"/>
+    <homepage href="http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Web"/>
     <description>Vendor tag missing</description>
     <offline/>
   </information>
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1main2mainAppDesc.jnlp
--- a/tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1main2mainAppDesc.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1main2mainAppDesc.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -41,8 +41,8 @@
       href="ManifestedJar-1main2mainNoAppDesc.jnlp">
    <information> 
       <title>Test Thread.getAllStackTraces</title> 
-      <vendor>NetX</vendor>
-      <homepage href="http://jnlp.sourceforge.net/netx/"/>
+      <vendor>IcedTea</vendor>
+      <homepage href="http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Web"/>
       <description>testing jar with manin class in manifest. Invalid xml exception should go out</description>
    </information> 
    <resources>
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1main2mainNoAppDesc.jnlp
--- a/tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1main2mainNoAppDesc.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1main2mainNoAppDesc.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -42,8 +42,8 @@
       href="ManifestedJar-1main2mainNoAppDesc.jnlp">
    <information> 
       <title>ManifestedJar-1main2mainNoAppDesc.jnlp</title> 
-      <vendor>NetX</vendor>
-      <homepage href="http://jnlp.sourceforge.net/netx/"/>
+      <vendor>IcedTea</vendor>
+      <homepage href="http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Web"/>
       <description>testing jar with manin class in manifest,  hello from manifestedjar1 should go out</description>
    </information> 
    <resources>
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1main2nothingNoAppDesc.jnlp
--- a/tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1main2nothingNoAppDesc.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1main2nothingNoAppDesc.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -42,8 +42,8 @@
       href="ManifestedJar-1main2nothingNoAppDesc.jnlp">
    <information> 
       <title>ManifestedJar-1main2nothingNoAppDesc</title> 
-      <vendor>NetX</vendor>
-      <homepage href="http://jnlp.sourceforge.net/netx/"/>
+      <vendor>IcedTea</vendor>
+      <homepage href="http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Web"/>
       <description>testing jar with manin class in manifest, hello from manifestedjar2 should be printed</description>
    </information> 
    <resources>
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1mainHaveAppDesc.jnlp
--- a/tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1mainHaveAppDesc.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1mainHaveAppDesc.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -41,8 +41,8 @@
       href="ManifestedJar-1mainHaveAppDesc.jnlp">
    <information> 
       <title>"ManifestedJar-1mainHaveAppDesc.jnlp</title> 
-      <vendor>NetX</vendor>
-      <homepage href="http://jnlp.sourceforge.net/netx/"/>
+      <vendor>IcedTea</vendor>
+      <homepage href="http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Web"/>
       <description>testing jar with manin class in manifest, hello from manifestedjar2 should be printed</description>
    </information> 
    <resources>
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1mainNoAppDesc.jnlp
--- a/tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1mainNoAppDesc.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1mainNoAppDesc.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -42,8 +42,8 @@
       href="ManifestedJar-1mainNoAppDesc.jnlp">
    <information> 
       <title>ManifestedJar-1mainNoAppDesc.jnlp</title> 
-      <vendor>NetX</vendor>
-      <homepage href="http://jnlp.sourceforge.net/netx/"/>
+      <vendor>IcedTea</vendor>
+      <homepage href="http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Web"/>
       <description>testing jar with manin class in manifest, hello from manifestedjar should be printed</description>
    </information> 
    <resources>
diff -r 60a2cbc4e542 -r f85f7c359b71 tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1noAppDesc.jnlp
--- a/tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1noAppDesc.jnlp	Tue Apr 03 12:13:24 2012 -0400
+++ b/tests/jnlp_tests/simple/ManifestedJar1/resources/ManifestedJar-1noAppDesc.jnlp	Tue Apr 03 16:04:55 2012 -0400
@@ -41,8 +41,8 @@
       href="ManifestedJar-1noAppDesc.jnlp">


From ddadacha at redhat.com  Tue Apr  3 13:07:23 2012
From: ddadacha at redhat.com (Danesh Dadachanji)
Date: Tue, 03 Apr 2012 16:07:23 -0400
Subject: [RFC][icedtea-web] Use IcedTea as the vendor for all JNLPs in
	test suite
In-Reply-To: <4F7B5752.70409@redhat.com>
References: <4F7B3DD8.80904@redhat.com> <4F7B4BD8.3010701@redhat.com>
	<4F7B4F11.3070306@redhat.com> <4F7B5326.2050005@redhat.com>
	<4F7B5639.1050600@redhat.com> <4F7B5736.70408@redhat.com>
	<4F7B5752.70409@redhat.com>
Message-ID: <4F7B587B.8080207@redhat.com>



On 03/04/12 04:02 PM, Omair Majid wrote:
> On 04/03/2012 04:01 PM, Danesh Dadachanji wrote:
>> On 03/04/12 03:57 PM, Omair Majid wrote:
>>> On 04/03/2012 03:44 PM, Danesh Dadachanji wrote:
>>>> The unit tests on the other hand are something I'd have to look at more
>>>> closely..
>>>
>>> But since those are self contained and located in a different directory
>>> (tests/netx/unit), they really shouldn't be affected by these changes.
>>>
>>
>> Right, I meant that if we wanted to change those, I would have to look
>> more closely at each one.
>
> Oh, I misunderstood.
>
>> In the mean time, can I push these to HEAD?
>
> Yes, please.
>

Thanks! Pushed here:
http://icedtea.classpath.org/hg/icedtea-web/rev/f85f7c359b71d4253c9e0fe9bedb599d1847fbbb

Cheers,
Danesh


From ddadacha at redhat.com  Tue Apr  3 12:44:38 2012
From: ddadacha at redhat.com (Danesh Dadachanji)
Date: Tue, 03 Apr 2012 15:44:38 -0400
Subject: [RFC][icedtea-web] Use IcedTea as the vendor for all JNLPs in
	test suite
In-Reply-To: <4F7B4F11.3070306@redhat.com>
References: <4F7B3DD8.80904@redhat.com> <4F7B4BD8.3010701@redhat.com>
	<4F7B4F11.3070306@redhat.com>
Message-ID: <4F7B5326.2050005@redhat.com>

On 03/04/12 03:27 PM, Omair Majid wrote:
> On 04/03/2012 03:13 PM, Danesh Dadachanji wrote:
>> On 03/04/12 02:13 PM, Danesh Dadachanji wrote:
>>> Hi,
>>>
>>> Many of the JNLPs in the test suite have various vendors (for no
>>> particular reason). For the community's sake, I'd like to replace all
>>> the ones under tests/jnlp_tests/ with IcedTea. I'm avoiding touching
>>> the unit test ones because I'm not 100% sure the vendor's being
>>> specified explicitly to be tested.
>>>
>>> This command should do the trick:
>>> $ find ./icedtea-web/tests/jnlp_tests/ -name *\.jnlp -exec sed -ie
>>> 's/<vendor>[A-Za-z0-9 ]*<\/vendor>/<vendor>IcedTea<\/vendor>/g' {} \;
>>>
>>> The attached patch has the result, the above worked as expected.
>>>
>>
>> Omair pointed out that I might as well change the homepage URL too, we
>> decided on this page[1] on IRC. I think the testing subheading is a good
>> location at which to point, thanks to Jiri for thinking of it!
>>
>> Command was:
>>
>> $ find ./icedtea-web/tests/jnlp_tests/ -name *\.jnlp -exec sed -ie
>> 's/<homepage href=".*"\/>/<homepage
>> href="http:\/\/icedtea.classpath.org\/wiki\/IcedTea-Web#Testing_IcedTea-Web"\/>/'
>> {} \;
>>
>> Any other comments?
>>
>
> Looks okay to me. Just one question: are there any tests that check for
> the value of homepage or vendor?

Nope, I checked that none of the reproducers try to access their values (if even possible?).

$ grep -ir 'homepage' jnlp_tests/ | grep -v '<homepage'
<nothing is printed>
$ grep -ir 'vendor' jnlp_tests/ | grep -v '<vendor>'
<Stuff from InformationTitleVendorParser which I can guarantee does not _use_ the values =) >

The unit tests on the other hand are something I'd have to look at more closely..

Cheers,
Danesh


From ddadacha at redhat.com  Tue Apr  3 14:48:35 2012
From: ddadacha at redhat.com (Danesh Dadachanji)
Date: Tue, 03 Apr 2012 17:48:35 -0400
Subject: [rfc][icedtea-web] reproducer for PR905
In-Reply-To: <4F709F99.30107@redhat.com>
References: <4F709F99.30107@redhat.com>
Message-ID: <4F7B7033.8030806@redhat.com>

Hi Jiri,

On 26/03/12 12:55 PM, Jiri Vanek wrote:
> Hi all!
>
> This reproducer is representing pr905 behaviour. All the tests except
> signed jar with parametrised archive are passing, which is correct, and
> the failing test is representing the issue.
>

Great job, thanks a lot for doing this! Please see comments below.

> However there is issue which make this reproducer ... useless. All the
> passing ones are nice, and we can include them (if you agree), but the
> falling one is signed applet (and simple signed applet test too) in
> browser. That means that user have to click on "trust" button :-/
>
> And I have currently no idea how to forward to plugin something like
> -Xtrustall :-/
>
> My only idea until now is some environment variable which will plugin
> forward to netx like Xtrustall. However - I have very strong feelings
> that this can be bloody security hole.

That definitely sounds like a bad security flaw. We need to setup something that user chooses to flag at runtime themselves (each time 
possibly), similarly to explicitly passing -Xtrustall to javaws. However, I'm not sure of any way that can do this securely. =(

One option off the top of my head, _just for testing_, might be to have a custom build flag for icedtea-web. If we pass it in when 
building (something like --build-for-testing), it could patch some of the code to skip the security checks? I'm not sure how suitable 
this would be though because it is modifying the code, no matter how small the modification is. =)

> (definietly is in windows, where you can use activeX to inject
> environment variable imho)
>
> So what do you think about the reproducer. Have it sense to push it
> without signed-applet-in-browser tests?
>

Firstly, I don't think this test should be pushed until the fix to PR905 is going into HEAD. I don't really see why having it in before 
hand is useful considering the issue is happening regardless, it may also scare off devs from running tests even more. =( Would you 
prefer to have it in before hand?

Secondly, regarding the applet-in-browser tests, I think we should keep them there but disable them until they can actually pass. Let's 
try to follow what was discussed in this email[1]. See my comments on AppletTestSigned below, they are similar.

> For future - any ideas how to create automated tests for signed applets
> in browser? (without awt robot)
>

Another idea could be to store some option (securely) accessible via itweb-settings..something like a checkbox for "Trust all applets 
run in the plugin" and then set this up properly on the test machine. I am again unclear as to how we would do this in a way that 
prevents outsiders from modifying the file that stores this flag on the FS. Do you know of any way in which we could save this 
"setting"? This does go against what I said above where this should be something specified at runtime of each applet but just throwing 
it out there. =) I suppose figuring this out would help us set something similar like an environment variable too though...

Some more comments in-line.

 > +2012-03-26  Jiri Vanek<jvanek at redhat.com>

2 spaces between Last name and <email> please.

 > +
 > +	Added tests for PR905 - parameters in jnlp/html application/applet resources
 > +	* tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.html:
 > +	html file for lunching signed applet
 > +	* tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.jnlp:
 > +	jnlp fiel for lunched signed applet

s/fiel/file

 > +	* tests/jnlp_tests/signed/AppletTestSigned/srcs/AppletTestSigned.java
 > +	body of signed applet
 > +	* tests/jnlp_tests/signed/AppletTestSigned/testcases/AppletTestSignedTests.java:
 > +	(AppletTestSignedTest) testing method to launch signed applet in javaws
 > +	(AppletTestSignedFirefoxTest) testing method to launch signed applet in
 > +	browser

I think this can be a separate changeset that can be pushed. Just handle the one that is meant to fail appropriately. I think the 
resolution from the email thread[1] was to disable them and make bugs for them (for now at least). Could you go through the changes 
mentioned below that affect AppletTestSigned and post a separate review please? Thanks!

[snip]

 > +	* tests/jnlp_tests/simple/ParametrizedJarUrl/testcases/ParametrizedJarUrlTests.java:
 > +	testaceses of above ParametrizedJarUrl/jnlps+htmls
 > +	Except regular launches are included also not parametrized  calls of parametrized jnlps

Can you reword this? I don't understand what you mean. =(

 > +	(parametrizedAppletTestSignedTest), (testParametrizedJarUrl2) and (testParametrizedJarUrlSigned2)

Uhh what about these 3? If there's no comment, I don't see a reason to keep then in the ChangeLog!

 > +	(parametrizedAppletTestSignedFirefoxTest) is the only one failing and so
 > +	representing PR905
 > +


[snip]
+++ b/tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.jnlp	Mon Mar 26 18:31:36 2012 +0200
...
+<?xml version="1.0" encoding="utf-8"?>
+<jnlp spec="1.0" href="AppletTestSigned.jnlp" codebase=".">
+    <information>
+        <title>AppletTest</title>
+        <vendor>NetX</vendor>
+        <homepage href="http://jnlp.sourceforge.net/netx/"/>

Could you make sure this is IcedTea for this and all future tests? It would be great to standardize this. In fact, you motivated me to 
submit a patch for changing all the past ones! =) Can you also change the homepage to IcedTea-Web's wiki page[2] too.


[snip]
+++ b/tests/jnlp_tests/simple/ParametrizedJarUrl/resources/ParametrizedJarAppletUrlSigned.jnlp	Mon Mar 26 18:31:36 2012 +0200
...
+    <resources>
+        <j2se version="1.4+"/>
+        <jar href="AppletTestSigned.jar?time=123456"/>

Could you please be consistent with the param? I see "time" in some places and "test" in others. I prefer "test" because I think "time" 
makes it look like the param has some actual use at a first glance. Note this is in both JNLP and Java files, when you execute 
javaws/the browser server.


[snip]
+++ b/tests/jnlp_tests/simple/ParametrizedJarUrl/testcases/ParametrizedJarUrlTests.java	Mon Mar 26 18:31:36 2012 +0200
...
+    @Test
+    public void parametrizedAppletJavawsTest2() throws Exception {
+        System.out.println("connecting ParametrizedJarAppletUrl2 request");
+        System.err.println("connecting ParametrizedJarAppletUrl2 request");
+        ServerAccess.ProcessResult pr = server.executeJavawsHeadless(null, "/ParametrizedJarAppletUrl2.jnlp?time=123456");

This is supposed to simulate running 'javaws ParametrizedJarAppletUrl2.jnlp?time=123456', right? Well this is strange because if I run 
this command from terminal, I get the following:

$ cd ./icedtea-web/build/tests.build/jnlp_test_server
$ javaws ParametrizedJarAppletUrl2.jnlp?time=123456
netx: Invalid jnlp file ParametrizedJarAppletUrl2.jnlp?time=123456

I hope I'm misunderstanding the purpose of the above test (and the others similar to it) but if this is the point, then something very 
strange is happening! Could you clarify what the above test is supposed to simulate?

The tests themselves look great, great to see that as much code is being reused as possible (WRT AppletTest/Simpletest1).

Thanks again for doing this!

Cheers,
Danesh

[1] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-March/017900.html
[2] http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Web


From ptisnovs at icedtea.classpath.org  Wed Apr  4 02:54:53 2012
From: ptisnovs at icedtea.classpath.org (ptisnovs at icedtea.classpath.org)
Date: Wed, 04 Apr 2012 09:54:53 +0000
Subject: /hg/gfx-test: * src/org/gfxtest/testsuites/ClippingCircleByRound...
Message-ID: <hg.b26c11e47283.1333533293.-6248649288953172555@icedtea.classpath.org>

changeset b26c11e47283 in /hg/gfx-test
details: http://icedtea.classpath.org/hg/gfx-test?cmd=changeset;node=b26c11e47283
author: Pavel Tisnovsky <ptisnovs at redhat.com>
date: Wed Apr 04 11:57:23 2012 +0200

	* src/org/gfxtest/testsuites/ClippingCircleByRoundRectangleShape.java:
	          Added new tests to this test suite.


diffstat:

 ChangeLog                                                         |    5 +
 src/org/gfxtest/testsuites/ClippingPathByRoundRectangleShape.java |  144 +++++++++-
 2 files changed, 147 insertions(+), 2 deletions(-)

diffs (194 lines):

diff -r 0ff7c385c559 -r b26c11e47283 ChangeLog
--- a/ChangeLog	Mon Mar 26 11:56:56 2012 +0200
+++ b/ChangeLog	Wed Apr 04 11:57:23 2012 +0200
@@ -1,3 +1,8 @@
+2012-04-04  Pavel Tisnovsky  <ptisnovs at redhat.com>
+
+	* src/org/gfxtest/testsuites/ClippingCircleByRoundRectangleShape.java:
+	Added new tests to this test suite.
+
 2012-03-26  Pavel Tisnovsky  <ptisnovs at redhat.com>
 
 	* src/org/gfxtest/testsuites/ClippingPathByEllipseShape.java:
diff -r 0ff7c385c559 -r b26c11e47283 src/org/gfxtest/testsuites/ClippingPathByRoundRectangleShape.java
--- a/src/org/gfxtest/testsuites/ClippingPathByRoundRectangleShape.java	Mon Mar 26 11:56:56 2012 +0200
+++ b/src/org/gfxtest/testsuites/ClippingPathByRoundRectangleShape.java	Wed Apr 04 11:57:23 2012 +0200
@@ -1,7 +1,7 @@
 /*
   Java gfx-test framework
 
-   Copyright (C) 2010, 2011  Red Hat
+   Copyright (C) 2010, 2011, 2012  Red Hat
 
 This file is part of IcedTea.
 
@@ -40,6 +40,7 @@
 
 package org.gfxtest.testsuites;
 
+import java.awt.BasicStroke;
 import java.awt.Graphics2D;
 
 
@@ -141,7 +142,6 @@
         graphics2d.draw(CommonPathsGenerator.createCubicPathFloat(image));
     }
 
-
     /**
      * Draw closed path clipped by a round rectangle shape.
      * 
@@ -259,6 +259,26 @@
     }
 
     /**
+     * Check if crossed closed path could be clipped by a round rectangle shape. Path is
+     * rendered using stroke paint with default stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipCrossedClosedPathByRoundRectangleShapeStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip round rectangle
+        CommonClippingOperations.renderClipRoundRectangle(image, graphics2d);
+        // set clip region and draw the path
+        drawCrossedClosedPathClippedByRoundRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
      * Check if crossed closed path could be clipped by a round rectangle shape.
      * Path is rendered using stroke paint with default stroke width.
      * 
@@ -279,6 +299,126 @@
     }
 
     /**
+     * Check if line path could be clipped by a round rectangle shape. Path is
+     * rendered using stroke paint with zero stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipLinePathByRoundRectangleShapeZeroStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRoundRectangle(image, graphics2d);
+        // set stroke color
+        CommonRenderingStyles.setStrokeColor(graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeZeroThick(graphics2d);
+        // set clip region and draw the path
+        drawLinePathClippedByRoundRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if quadratic path could be clipped by a round rectangle shape. Path is
+     * rendered using stroke paint with zero stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipQuadraticPathByRoundRectangleShapeZeroStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRoundRectangle(image, graphics2d);
+        // set stroke color
+        CommonRenderingStyles.setStrokeColor(graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeZeroThick(graphics2d);
+        // set clip region and draw the path
+        drawQuadraticPathClippedByRoundRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if cubic path could be clipped by a round rectangle shape. Path is
+     * rendered using stroke paint with zero stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipCubicPathByRoundRectangleShapeZeroStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRoundRectangle(image, graphics2d);
+        // set stroke color
+        CommonRenderingStyles.setStrokeColor(graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeZeroThick(graphics2d);
+        // set clip region and draw the path
+        drawCubicPathClippedByRoundRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if closed path could be clipped by a round rectangle shape. Path is
+     * rendered using stroke paint with zero stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipClosedPathByRoundRectangleShapeZeroStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRoundRectangle(image, graphics2d);
+        // set stroke color
+        CommonRenderingStyles.setStrokeColor(graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeZeroThick(graphics2d);
+        // set clip region and draw the path
+        drawClosedPathClippedByRoundRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if crossed closed path could be clipped by a round rectangle shape. Path is
+     * rendered using stroke paint with zero stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipCrossedClosedPathByRoundRectangleShapeZeroStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRoundRectangle(image, graphics2d);
+        // set stroke color
+        CommonRenderingStyles.setStrokeColor(graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeZeroThick(graphics2d);
+        // set clip region and draw the path
+        drawCrossedClosedPathClippedByRoundRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
      * Entry point to the test suite.
      * 
      * @param args


From ahughes at redhat.com  Wed Apr  4 06:59:44 2012
From: ahughes at redhat.com (Andrew Hughes)
Date: Wed, 04 Apr 2012 09:59:44 -0400 (EDT)
Subject: Reviewer needed: backport of "6792400: Avoid loading of
	Normalizer	resources,
	for simple uses" into IcedTea6-1.10 and IcedTea6-1.11
In-Reply-To: <4F7AFEFC.4040701@redhat.com>
Message-ID: <1bb9b785-9510-4702-acd4-6a025e137a71@zmail17.collab.prod.int.phx2.redhat.com>

----- Original Message -----
> Hi,
> 
> I'd like to backport "6792400: Avoid loading of Normalizer resources,
> for simple uses" into IcedTea6-1.10 and
> IcedTea6-1.11. This backport is already pushed in IcedTea6 HEAD (w/o
> problems).
> 
> hg diffs generated against recent IcedTea6-1.10 and IcedTea6-1.11
> versions are stored in attachments (incl. NEWS entry).
> 
> 
> ChangeLog entry:
> 
> 2012-04-03  Pavel Tisnovsky  <ptisnovs at redhat.com>
> 
>         *
>         patches/openjdk/6792400-Avoid_loading_Normalizer_resources.patch:
>         Backport of: 6792400: Avoid loading of Normalizer resources
>         for simple uses
>         * NEWS: Mention backport.
>         * Makefile.am: Updated
> 
> 
> Can anybody please review these backports?
> 

Looks good to me.  I'm not keen on the capitalisation but I can live with it.

> Thank you in advance,
> Pavel T.
> 
> 
> [Text Documents:icedtea6-1.10.patch]
> 
> 
> [Text Documents:icedtea6-1.11.patch]
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-patch
Size: 3212 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120404/99692313/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-patch
Size: 3158 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120404/99692313/attachment-0001.bin 

From jvanek at redhat.com  Wed Apr  4 07:42:09 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Wed, 04 Apr 2012 16:42:09 +0200
Subject: Fwd: Re: [rfc][icedtea-web] reproducer for PR905
In-Reply-To: <4F7C4F16.3000802@redhat.com>
References: <4F7C4F16.3000802@redhat.com>
Message-ID: <4F7C5DC1.2030502@redhat.com>

uups. Looks Like I have forgot to cc distro-pkg. Please reply to this one.

-------- Original Message --------
Subject: Re: [rfc][icedtea-web] reproducer for PR905
Date: Wed, 04 Apr 2012 15:39:34 +0200
From: Jiri Vanek <jvanek at redhat.com>
To: Danesh Dadachanji <ddadacha at redhat.com>,  Pavel Tisnovsky <ptisnovs at redhat.com>

On 04/03/2012 11:48 PM, Danesh Dadachanji wrote:

I have cc also Pavel and Omair because -XtrustAll for applets done wrong can be quite serious.

> Hi Jiri,
>
> On 26/03/12 12:55 PM, Jiri Vanek wrote:
>> Hi all!
>>
>> This reproducer is representing pr905 behaviour. All the tests except
>> signed jar with parametrised archive are passing, which is correct, and
>> the failing test is representing the issue.
>>
>
> Great job, thanks a lot for doing this! Please see comments below.
>
>> However there is issue which make this reproducer ... useless. All the
>> passing ones are nice, and we can include them (if you agree), but the
>> falling one is signed applet (and simple signed applet test too) in
>> browser. That means that user have to click on "trust" button :-/
>>
>> And I have currently no idea how to forward to plugin something like
>> -Xtrustall :-/
>>
>> My only idea until now is some environment variable which will plugin
>> forward to netx like Xtrustall. However - I have very strong feelings
>> that this can be bloody security hole.
>
> That definitely sounds like a bad security flaw. We need to setup something that user chooses to
> flag at runtime themselves (each time possibly), similarly to explicitly passing -Xtrustall to
> javaws. However, I'm not sure of any way that can do this securely. =(
>
> One option off the top of my head, _just for testing_, might be to have a custom build flag for
This will be probably the only way. But I dont like it:(
I like also the way via itweb-settings, especially when it will be possible via commandline, but it
looks wrong in same way as environment variable.
> icedtea-web. If we pass it in when building (something like --build-for-testing), it could patch
> some of the code to skip the security checks? I'm not sure how suitable this would be though because
> it is modifying the code, no matter how small the modification is. =)
>
>> (definietly is in windows, where you can use activeX to inject
>> environment variable imho)
>>
>> So what do you think about the reproducer. Have it sense to push it
>> without signed-applet-in-browser tests?
>>
>
> Firstly, I don't think this test should be pushed until the fix to PR905 is going into HEAD. I don't
IMHO failing tests representing issue SHOULD be pushed. Omair have temporarily suspended his effort
to ignore failing tests.
> really see why having it in before hand is useful considering the issue is happening regardless, it
> may also scare off devs from running tests even more. =( Would you prefer to have it in before hand?
Definitely O:)
But there is the issue with necessary click right now:-/
Without signed-parametrized applet they have just small reason.
I'm for:
   to push the parts which are passing
   to push the signed applet
   to push failing test
BUT to disable last two which are failing due to necessary click:(
>
> Secondly, regarding the applet-in-browser tests, I think we should keep them there but disable them
> until they can actually pass. Let's try to follow what was discussed in this email[1]. See my
> comments on AppletTestSigned below, they are similar.
>
>> For future - any ideas how to create automated tests for signed applets
>> in browser? (without awt robot)
>>
>
> Another idea could be to store some option (securely) accessible via itweb-settings..something like
> a checkbox for "Trust all applets run in the plugin" and then set this up properly on the test
> machine. I am again unclear as to how we would do this in a way that prevents outsiders from
> modifying the file that stores this flag on the FS. Do you know of any way in which we could save
hmm... some file which can just root modify, and to read it for -XtrustAll? hmm.. this can work!
I believe this setting should be held out of  itweb-settings.. What about ~/.icedtea ? But probably
some location where just root can write will be better. As this is intended just for testing
reasons, I'm for direct /etc.
> this "setting"? This does go against what I said above where this should be something specified at
> runtime of each applet but just throwing it out there. =) I suppose figuring this out would help us
> set something similar like an environment variable too though...
>
> Some more comments in-line.
>
>  > +2012-03-26 Jiri Vanek<jvanek at redhat.com>
>
> 2 spaces between Last name and <email> please.
>
>  > +
>  > + Added tests for PR905 - parameters in jnlp/html application/applet resources
>  > + * tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.html:
>  > + html file for lunching signed applet
>  > + * tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.jnlp:
>  > + jnlp fiel for lunched signed applet
>
> s/fiel/file
O:)
>
>  > + * tests/jnlp_tests/signed/AppletTestSigned/srcs/AppletTestSigned.java
>  > + body of signed applet
>  > + * tests/jnlp_tests/signed/AppletTestSigned/testcases/AppletTestSignedTests.java:
>  > + (AppletTestSignedTest) testing method to launch signed applet in javaws
>  > + (AppletTestSignedFirefoxTest) testing method to launch signed applet in
>  > + browser
>
> I think this can be a separate changeset that can be pushed. Just handle the one that is meant to
> fail appropriately. I think the resolution from the email thread[1] was to disable them and make
> bugs for them (for now at least). Could you go through the changes mentioned below that affect
> AppletTestSigned and post a separate review please? Thanks!

Yes (definitely :) ). But have no sense unless signed applets can be run automaticaly or as I told
above.
>
> [snip]
>
>  > + * tests/jnlp_tests/simple/ParametrizedJarUrl/testcases/ParametrizedJarUrlTests.java:
>  > + testaceses of above ParametrizedJarUrl/jnlps+htmls
>  > + Except regular launches are included also not parametrized calls of parametrized jnlps
>
> Can you reword this? I don't understand what you mean. =(
I can't :D
>
>  > + (parametrizedAppletTestSignedTest), (testParametrizedJarUrl2) and (testParametrizedJarUrlSigned2)
>
> Uhh what about these 3? If there's no comment, I don't see a reason to keep then in the ChangeLog!\
As you command :)
>
>  > + (parametrizedAppletTestSignedFirefoxTest) is the only one failing and so
>  > + representing PR905
>  > +
>
>
> [snip]
> +++ b/tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.jnlp Mon Mar 26 18:31:36
> 2012 +0200
> ...
> +<?xml version="1.0" encoding="utf-8"?>
> +<jnlp spec="1.0" href="AppletTestSigned.jnlp" codebase=".">
> + <information>
> + <title>AppletTest</title>
> + <vendor>NetX</vendor>
> + <homepage href="http://jnlp.sourceforge.net/netx/"/>
>
> Could you make sure this is IcedTea for this and all future tests? It would be great to standardize
> this. In fact, you motivated me to submit a patch for changing all the past ones! =) Can you also
> change the homepage to IcedTea-Web's wiki page[2] too.

Sure!
>
>
> [snip]
> +++ b/tests/jnlp_tests/simple/ParametrizedJarUrl/resources/ParametrizedJarAppletUrlSigned.jnlp Mon
> Mar 26 18:31:36 2012 +0200
> ...
> + <resources>
> + <j2se version="1.4+"/>
> + <jar href="AppletTestSigned.jar?time=123456"/>
>
> Could you please be consistent with the param? I see "time" in some places and "test" in others. I
> prefer "test" because I think "time" makes it look like the param has some actual use at a first
> glance. Note this is in both JNLP and Java files, when you execute javaws/the browser server.
>
>
> [snip]
> +++ b/tests/jnlp_tests/simple/ParametrizedJarUrl/testcases/ParametrizedJarUrlTests.java Mon Mar 26
> 18:31:36 2012 +0200
> ...
> + @Test
> + public void parametrizedAppletJavawsTest2() throws Exception {
> + System.out.println("connecting ParametrizedJarAppletUrl2 request");
> + System.err.println("connecting ParametrizedJarAppletUrl2 request");
> + ServerAccess.ProcessResult pr = server.executeJavawsHeadless(null,
> "/ParametrizedJarAppletUrl2.jnlp?time=123456");
>
> This is supposed to simulate running 'javaws ParametrizedJarAppletUrl2.jnlp?time=123456', right?
> Well this is strange because if I run this command from terminal, I get the following:
>
> $ cd ./icedtea-web/build/tests.build/jnlp_test_server
> $ javaws ParametrizedJarAppletUrl2.jnlp?time=123456
> netx: Invalid jnlp file ParametrizedJarAppletUrl2.jnlp?time=123456
>
> I hope I'm misunderstanding the purpose of the above test (and the others similar to it) but if this
> is the point, then something very strange is happening! Could you clarify what the above test is
> supposed to simulate?

Yes I can :) You must run it as url :)  eg javaws
http://localhost:44321/ParametrizedJarAppletUrl2.jnlp?time=123456

Then everything behind ? is translated as parameter for server.

If you are launching it as you are, then it is considered to be file, where question mark have no
special meaning;)
>
> The tests themselves look great, great to see that as much code is being reused as possible (WRT
> AppletTest/Simpletest1).
>
> Thanks again for doing this!
>
> Cheers,
> Danesh
>
> [1] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-March/017900.html
Suspended
> [2] http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Web
sure!



J.


From thomas at m3y3r.de  Wed Apr  4 07:57:40 2012
From: thomas at m3y3r.de (Thomas Meyer)
Date: Wed, 04 Apr 2012 16:57:40 +0200
Subject: [RFC] Fix IndexOutOfBoundException because of corrupted entry
	in recently_used file
In-Reply-To: <4F7B0E34.7010209@redhat.com>
References: <1332938501.1397.15.camel@localhost.localdomain>
	<4F79A620.2090702@redhat.com>
	<1333447622.5010.11.camel@localhost.localdomain>
	<4F7AE134.7080500@redhat.com>
	<1333458882.5010.14.camel@localhost.localdomain>
	<4F7B0E34.7010209@redhat.com>
Message-ID: <1333551460.6613.13.camel@localhost.localdomain>

Am Dienstag, den 03.04.2012, 16:50 +0200 schrieb Jiri Vanek:
> Thanx for test! Logic itself is good, but there are two mistakes which causes the test to be not-working.
> See notes inline for them.

Hi,

I hacked a bit on this today. please have a look at the attached patch.

I moved all the format checks in the CacheLRUWrapper.load() method. that
is the place were I think they actually belong.

I guess these changes will break the CacheReproducerTest as no more
LRUExceptions are thrown.

what do you think about this approach? does this make sense for you?

with kind regards
thomas


-------------- next part --------------
A non-text attachment was scrubbed...
Name: check-cache-data.patch
Type: text/x-patch
Size: 12639 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120404/bc10af29/check-cache-data.patch 

From ddadacha at redhat.com  Wed Apr  4 08:40:00 2012
From: ddadacha at redhat.com (Danesh Dadachanji)
Date: Wed, 04 Apr 2012 11:40:00 -0400
Subject: Fwd: Re: [rfc][icedtea-web] reproducer for PR905
In-Reply-To: <4F7C5DC1.2030502@redhat.com>
References: <4F7C4F16.3000802@redhat.com> <4F7C5DC1.2030502@redhat.com>
Message-ID: <4F7C6B50.1050802@redhat.com>

Adding CCs.

Cheers,
Danesh

On 04/04/12 10:42 AM, Jiri Vanek wrote:
> uups. Looks Like I have forgot to cc distro-pkg. Please reply to this one.
>
> -------- Original Message --------
> Subject: Re: [rfc][icedtea-web] reproducer for PR905
> Date: Wed, 04 Apr 2012 15:39:34 +0200
> From: Jiri Vanek <jvanek at redhat.com>
> To: Danesh Dadachanji <ddadacha at redhat.com>, Pavel Tisnovsky <ptisnovs at redhat.com>
>
> On 04/03/2012 11:48 PM, Danesh Dadachanji wrote:
>
> I have cc also Pavel and Omair because -XtrustAll for applets done wrong can be quite serious.
>
>> Hi Jiri,
>>
>> On 26/03/12 12:55 PM, Jiri Vanek wrote:
>>> Hi all!
>>>
>>> This reproducer is representing pr905 behaviour. All the tests except
>>> signed jar with parametrised archive are passing, which is correct, and
>>> the failing test is representing the issue.
>>>
>>
>> Great job, thanks a lot for doing this! Please see comments below.
>>
>>> However there is issue which make this reproducer ... useless. All the
>>> passing ones are nice, and we can include them (if you agree), but the
>>> falling one is signed applet (and simple signed applet test too) in
>>> browser. That means that user have to click on "trust" button :-/
>>>
>>> And I have currently no idea how to forward to plugin something like
>>> -Xtrustall :-/
>>>
>>> My only idea until now is some environment variable which will plugin
>>> forward to netx like Xtrustall. However - I have very strong feelings
>>> that this can be bloody security hole.
>>
>> That definitely sounds like a bad security flaw. We need to setup something that user chooses to
>> flag at runtime themselves (each time possibly), similarly to explicitly passing -Xtrustall to
>> javaws. However, I'm not sure of any way that can do this securely. =(
>>
>> One option off the top of my head, _just for testing_, might be to have a custom build flag for
> This will be probably the only way. But I dont like it:(
> I like also the way via itweb-settings, especially when it will be possible via commandline, but it
> looks wrong in same way as environment variable.
>> icedtea-web. If we pass it in when building (something like --build-for-testing), it could patch
>> some of the code to skip the security checks? I'm not sure how suitable this would be though because
>> it is modifying the code, no matter how small the modification is. =)
>>
>>> (definietly is in windows, where you can use activeX to inject
>>> environment variable imho)
>>>
>>> So what do you think about the reproducer. Have it sense to push it
>>> without signed-applet-in-browser tests?
>>>
>>
>> Firstly, I don't think this test should be pushed until the fix to PR905 is going into HEAD. I don't
> IMHO failing tests representing issue SHOULD be pushed. Omair have temporarily suspended his effort
> to ignore failing tests.
>> really see why having it in before hand is useful considering the issue is happening regardless, it
>> may also scare off devs from running tests even more. =( Would you prefer to have it in before hand?
> Definitely O:)
> But there is the issue with necessary click right now:-/
> Without signed-parametrized applet they have just small reason.
> I'm for:
> to push the parts which are passing
> to push the signed applet
> to push failing test
> BUT to disable last two which are failing due to necessary click:(
>>
>> Secondly, regarding the applet-in-browser tests, I think we should keep them there but disable them
>> until they can actually pass. Let's try to follow what was discussed in this email[1]. See my
>> comments on AppletTestSigned below, they are similar.
>>
>>> For future - any ideas how to create automated tests for signed applets
>>> in browser? (without awt robot)
>>>
>>
>> Another idea could be to store some option (securely) accessible via itweb-settings..something like
>> a checkbox for "Trust all applets run in the plugin" and then set this up properly on the test
>> machine. I am again unclear as to how we would do this in a way that prevents outsiders from
>> modifying the file that stores this flag on the FS. Do you know of any way in which we could save
> hmm... some file which can just root modify, and to read it for -XtrustAll? hmm.. this can work!
> I believe this setting should be held out of itweb-settings.. What about ~/.icedtea ? But probably
> some location where just root can write will be better. As this is intended just for testing
> reasons, I'm for direct /etc.
>> this "setting"? This does go against what I said above where this should be something specified at
>> runtime of each applet but just throwing it out there. =) I suppose figuring this out would help us
>> set something similar like an environment variable too though...
>>
>> Some more comments in-line.
>>
>> > +2012-03-26 Jiri Vanek<jvanek at redhat.com>
>>
>> 2 spaces between Last name and <email> please.
>>
>> > +
>> > + Added tests for PR905 - parameters in jnlp/html application/applet resources
>> > + * tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.html:
>> > + html file for lunching signed applet
>> > + * tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.jnlp:
>> > + jnlp fiel for lunched signed applet
>>
>> s/fiel/file
> O:)
>>
>> > + * tests/jnlp_tests/signed/AppletTestSigned/srcs/AppletTestSigned.java
>> > + body of signed applet
>> > + * tests/jnlp_tests/signed/AppletTestSigned/testcases/AppletTestSignedTests.java:
>> > + (AppletTestSignedTest) testing method to launch signed applet in javaws
>> > + (AppletTestSignedFirefoxTest) testing method to launch signed applet in
>> > + browser
>>
>> I think this can be a separate changeset that can be pushed. Just handle the one that is meant to
>> fail appropriately. I think the resolution from the email thread[1] was to disable them and make
>> bugs for them (for now at least). Could you go through the changes mentioned below that affect
>> AppletTestSigned and post a separate review please? Thanks!
>
> Yes (definitely :) ). But have no sense unless signed applets can be run automaticaly or as I told
> above.
>>
>> [snip]
>>
>> > + * tests/jnlp_tests/simple/ParametrizedJarUrl/testcases/ParametrizedJarUrlTests.java:
>> > + testaceses of above ParametrizedJarUrl/jnlps+htmls
>> > + Except regular launches are included also not parametrized calls of parametrized jnlps
>>
>> Can you reword this? I don't understand what you mean. =(
> I can't :D
>>
>> > + (parametrizedAppletTestSignedTest), (testParametrizedJarUrl2) and (testParametrizedJarUrlSigned2)
>>
>> Uhh what about these 3? If there's no comment, I don't see a reason to keep then in the ChangeLog!\
> As you command :)
>>
>> > + (parametrizedAppletTestSignedFirefoxTest) is the only one failing and so
>> > + representing PR905
>> > +
>>
>>
>> [snip]
>> +++ b/tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.jnlp Mon Mar 26 18:31:36
>> 2012 +0200
>> ...
>> +<?xml version="1.0" encoding="utf-8"?>
>> +<jnlp spec="1.0" href="AppletTestSigned.jnlp" codebase=".">
>> + <information>
>> + <title>AppletTest</title>
>> + <vendor>NetX</vendor>
>> + <homepage href="http://jnlp.sourceforge.net/netx/"/>
>>
>> Could you make sure this is IcedTea for this and all future tests? It would be great to standardize
>> this. In fact, you motivated me to submit a patch for changing all the past ones! =) Can you also
>> change the homepage to IcedTea-Web's wiki page[2] too.
>
> Sure!
>>
>>
>> [snip]
>> +++ b/tests/jnlp_tests/simple/ParametrizedJarUrl/resources/ParametrizedJarAppletUrlSigned.jnlp Mon
>> Mar 26 18:31:36 2012 +0200
>> ...
>> + <resources>
>> + <j2se version="1.4+"/>
>> + <jar href="AppletTestSigned.jar?time=123456"/>
>>
>> Could you please be consistent with the param? I see "time" in some places and "test" in others. I
>> prefer "test" because I think "time" makes it look like the param has some actual use at a first
>> glance. Note this is in both JNLP and Java files, when you execute javaws/the browser server.
>>
>>
>> [snip]
>> +++ b/tests/jnlp_tests/simple/ParametrizedJarUrl/testcases/ParametrizedJarUrlTests.java Mon Mar 26
>> 18:31:36 2012 +0200
>> ...
>> + @Test
>> + public void parametrizedAppletJavawsTest2() throws Exception {
>> + System.out.println("connecting ParametrizedJarAppletUrl2 request");
>> + System.err.println("connecting ParametrizedJarAppletUrl2 request");
>> + ServerAccess.ProcessResult pr = server.executeJavawsHeadless(null,
>> "/ParametrizedJarAppletUrl2.jnlp?time=123456");
>>
>> This is supposed to simulate running 'javaws ParametrizedJarAppletUrl2.jnlp?time=123456', right?
>> Well this is strange because if I run this command from terminal, I get the following:
>>
>> $ cd ./icedtea-web/build/tests.build/jnlp_test_server
>> $ javaws ParametrizedJarAppletUrl2.jnlp?time=123456
>> netx: Invalid jnlp file ParametrizedJarAppletUrl2.jnlp?time=123456
>>
>> I hope I'm misunderstanding the purpose of the above test (and the others similar to it) but if this
>> is the point, then something very strange is happening! Could you clarify what the above test is
>> supposed to simulate?
>
> Yes I can :) You must run it as url :) eg javaws
> http://localhost:44321/ParametrizedJarAppletUrl2.jnlp?time=123456
>
> Then everything behind ? is translated as parameter for server.
>
> If you are launching it as you are, then it is considered to be file, where question mark have no
> special meaning;)
>>
>> The tests themselves look great, great to see that as much code is being reused as possible (WRT
>> AppletTest/Simpletest1).
>>
>> Thanks again for doing this!
>>
>> Cheers,
>> Danesh
>>
>> [1] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-March/017900.html
> Suspended
>> [2] http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Web
> sure!
>
>
>
> J.


From dbhole at redhat.com  Wed Apr  4 08:43:15 2012
From: dbhole at redhat.com (Deepak Bhole)
Date: Wed, 4 Apr 2012 11:43:15 -0400
Subject: Fwd: Re: [rfc][icedtea-web] reproducer for PR905
In-Reply-To: <4F7C6B50.1050802@redhat.com>
References: <4F7C4F16.3000802@redhat.com> <4F7C5DC1.2030502@redhat.com>
	<4F7C6B50.1050802@redhat.com>
Message-ID: <20120404154314.GF23765@redhat.com>

* Danesh Dadachanji <ddadacha at redhat.com> [2012-04-04 11:40]:
> Adding CCs.
> 
> Cheers,
> Danesh
> 
> On 04/04/12 10:42 AM, Jiri Vanek wrote:
> >uups. Looks Like I have forgot to cc distro-pkg. Please reply to this one.
> >
> >-------- Original Message --------
> >Subject: Re: [rfc][icedtea-web] reproducer for PR905
> >Date: Wed, 04 Apr 2012 15:39:34 +0200
> >From: Jiri Vanek <jvanek at redhat.com>
> >To: Danesh Dadachanji <ddadacha at redhat.com>, Pavel Tisnovsky <ptisnovs at redhat.com>
> >
> >On 04/03/2012 11:48 PM, Danesh Dadachanji wrote:
> >
> >I have cc also Pavel and Omair because -XtrustAll for applets done wrong can be quite serious.
> >
> >>Hi Jiri,
> >>
> >>On 26/03/12 12:55 PM, Jiri Vanek wrote:
> >>>Hi all!
> >>>
> >>>This reproducer is representing pr905 behaviour. All the tests except
> >>>signed jar with parametrised archive are passing, which is correct, and
> >>>the failing test is representing the issue.
> >>>
> >>
> >>Great job, thanks a lot for doing this! Please see comments below.
> >>
> >>>However there is issue which make this reproducer ... useless. All the
> >>>passing ones are nice, and we can include them (if you agree), but the
> >>>falling one is signed applet (and simple signed applet test too) in
> >>>browser. That means that user have to click on "trust" button :-/
> >>>
> >>>And I have currently no idea how to forward to plugin something like
> >>>-Xtrustall :-/
> >>>
> >>>My only idea until now is some environment variable which will plugin
> >>>forward to netx like Xtrustall. However - I have very strong feelings
> >>>that this can be bloody security hole.
> >>
> >>That definitely sounds like a bad security flaw. We need to setup something that user chooses to
> >>flag at runtime themselves (each time possibly), similarly to explicitly passing -Xtrustall to
> >>javaws. However, I'm not sure of any way that can do this securely. =(
> >>
> >>One option off the top of my head, _just for testing_, might be to have a custom build flag for
> >This will be probably the only way. But I dont like it:(
> >I like also the way via itweb-settings, especially when it will be possible via commandline, but it
> >looks wrong in same way as environment variable.
> >>icedtea-web. If we pass it in when building (something like --build-for-testing), it could patch
> >>some of the code to skip the security checks? I'm not sure how suitable this would be though because
> >>it is modifying the code, no matter how small the modification is. =)
> >>
> >>>(definietly is in windows, where you can use activeX to inject
> >>>environment variable imho)
> >>>
> >>>So what do you think about the reproducer. Have it sense to push it
> >>>without signed-applet-in-browser tests?
> >>>
> >>
> >>Firstly, I don't think this test should be pushed until the fix to PR905 is going into HEAD. I don't
> >IMHO failing tests representing issue SHOULD be pushed. Omair have temporarily suspended his effort
> >to ignore failing tests.
> >>really see why having it in before hand is useful considering the issue is happening regardless, it
> >>may also scare off devs from running tests even more. =( Would you prefer to have it in before hand?
> >Definitely O:)
> >But there is the issue with necessary click right now:-/
> >Without signed-parametrized applet they have just small reason.
> >I'm for:
> >to push the parts which are passing
> >to push the signed applet
> >to push failing test
> >BUT to disable last two which are failing due to necessary click:(
> >>
> >>Secondly, regarding the applet-in-browser tests, I think we should keep them there but disable them
> >>until they can actually pass. Let's try to follow what was discussed in this email[1]. See my
> >>comments on AppletTestSigned below, they are similar.
> >>
> >>>For future - any ideas how to create automated tests for signed applets
> >>>in browser? (without awt robot)
> >>>
> >>
> >>Another idea could be to store some option (securely) accessible via itweb-settings..something like
> >>a checkbox for "Trust all applets run in the plugin" and then set this up properly on the test
> >>machine. I am again unclear as to how we would do this in a way that prevents outsiders from
> >>modifying the file that stores this flag on the FS. Do you know of any way in which we could save
> >hmm... some file which can just root modify, and to read it for -XtrustAll? hmm.. this can work!
> >I believe this setting should be held out of itweb-settings.. What about ~/.icedtea ? But probably
> >some location where just root can write will be better. As this is intended just for testing
> >reasons, I'm for direct /etc.
> >>this "setting"? This does go against what I said above where this should be something specified at
> >>runtime of each applet but just throwing it out there. =) I suppose figuring this out would help us
> >>set something similar like an environment variable too though...
> >>
> >>Some more comments in-line.
> >>
> >>> +2012-03-26 Jiri Vanek<jvanek at redhat.com>
> >>
> >>2 spaces between Last name and <email> please.
> >>
> >>> +
> >>> + Added tests for PR905 - parameters in jnlp/html application/applet resources
> >>> + * tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.html:
> >>> + html file for lunching signed applet
> >>> + * tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.jnlp:
> >>> + jnlp fiel for lunched signed applet
> >>
> >>s/fiel/file
> >O:)
> >>
> >>> + * tests/jnlp_tests/signed/AppletTestSigned/srcs/AppletTestSigned.java
> >>> + body of signed applet
> >>> + * tests/jnlp_tests/signed/AppletTestSigned/testcases/AppletTestSignedTests.java:
> >>> + (AppletTestSignedTest) testing method to launch signed applet in javaws
> >>> + (AppletTestSignedFirefoxTest) testing method to launch signed applet in
> >>> + browser
> >>
> >>I think this can be a separate changeset that can be pushed. Just handle the one that is meant to
> >>fail appropriately. I think the resolution from the email thread[1] was to disable them and make
> >>bugs for them (for now at least). Could you go through the changes mentioned below that affect
> >>AppletTestSigned and post a separate review please? Thanks!
> >
> >Yes (definitely :) ). But have no sense unless signed applets can be run automaticaly or as I told
> >above.
> >>


How about creating a cert, importing it and then signing everything with that
cert?

Cheers,
Deepak



From jvanek at redhat.com  Wed Apr  4 08:56:30 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Wed, 04 Apr 2012 17:56:30 +0200
Subject: Fwd: Re: [rfc][icedtea-web] reproducer for PR905
In-Reply-To: <20120404154314.GF23765@redhat.com>
References: <4F7C4F16.3000802@redhat.com> <4F7C5DC1.2030502@redhat.com>
	<4F7C6B50.1050802@redhat.com> <20120404154314.GF23765@redhat.com>
Message-ID: <4F7C6F2E.8080109@redhat.com>

...snip...
>>>>
>
>
> How about creating a cert, importing it and then signing everything with that
> cert?
>

Applet is then not asking user anymore???

If this is true than this is granzgenial:)

It will need some logic to import the certs to browser, but it will be needed anyway (see 
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-March/017799.html for more about browser 
detection)

J.


From dbhole at redhat.com  Wed Apr  4 08:58:54 2012
From: dbhole at redhat.com (Deepak Bhole)
Date: Wed, 4 Apr 2012 11:58:54 -0400
Subject: Fwd: Re: [rfc][icedtea-web] reproducer for PR905
In-Reply-To: <4F7C6F2E.8080109@redhat.com>
References: <4F7C4F16.3000802@redhat.com> <4F7C5DC1.2030502@redhat.com>
	<4F7C6B50.1050802@redhat.com> <20120404154314.GF23765@redhat.com>
	<4F7C6F2E.8080109@redhat.com>
Message-ID: <20120404155853.GH23765@redhat.com>

* Jiri Vanek <jvanek at redhat.com> [2012-04-04 11:55]:
> ...snip...
> >>>>
> >
> >
> >How about creating a cert, importing it and then signing everything with that
> >cert?
> >
> 
> Applet is then not asking user anymore???
> 
> If this is true than this is granzgenial:)
> 
> It will need some logic to import the certs to browser, but it will
> be needed anyway (see http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-March/017799.html
> for more about browser detection)
> 

If you choose to always trust it, yes it shouldn't ask any more.

Cheers,
Deepak


From jvanek at redhat.com  Wed Apr  4 09:05:27 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Wed, 04 Apr 2012 18:05:27 +0200
Subject: Fwd: Re: [rfc][icedtea-web] reproducer for PR905
In-Reply-To: <20120404155853.GH23765@redhat.com>
References: <4F7C4F16.3000802@redhat.com> <4F7C5DC1.2030502@redhat.com>
	<4F7C6B50.1050802@redhat.com> <20120404154314.GF23765@redhat.com>
	<4F7C6F2E.8080109@redhat.com> <20120404155853.GH23765@redhat.com>
Message-ID: <4F7C7147.9010707@redhat.com>

On 04/04/2012 05:58 PM, Deepak Bhole wrote:
> * Jiri Vanek<jvanek at redhat.com>  [2012-04-04 11:55]:
>> ...snip...
>>>>>>
>>>
>>>
>>> How about creating a cert, importing it and then signing everything with that
>>> cert?
>>>
>>
>> Applet is then not asking user anymore???
>>
>> If this is true than this is granzgenial:)
>>
>> It will need some logic to import the certs to browser, but it will
>> be needed anyway (see http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-March/017799.html
>> for more about browser detection)
>>
>
> If you choose to always trust it, yes it shouldn't ask any more.

hmmm... Can be much  harder then to control this fully-automatically.
(means create certificate during make is easy, sign all stuff with this certificate is easy, import 
  certificate to browsers should be also easy (just cp I believe), force the browser to force this 
new certificate without prompt can be however impossible :( )
If it is possible  to accept it just oncetimes for all future-generated certificates - it will do 
the job as well.

I would like to avoid one static certificate which have to be refreshed each .. some times...


>
> Cheers,
> Deepak



From dbhole at redhat.com  Wed Apr  4 09:11:37 2012
From: dbhole at redhat.com (Deepak Bhole)
Date: Wed, 4 Apr 2012 12:11:37 -0400
Subject: Fwd: Re: [rfc][icedtea-web] reproducer for PR905
In-Reply-To: <4F7C7147.9010707@redhat.com>
References: <4F7C4F16.3000802@redhat.com> <4F7C5DC1.2030502@redhat.com>
	<4F7C6B50.1050802@redhat.com> <20120404154314.GF23765@redhat.com>
	<4F7C6F2E.8080109@redhat.com> <20120404155853.GH23765@redhat.com>
	<4F7C7147.9010707@redhat.com>
Message-ID: <20120404161136.GJ23765@redhat.com>

* Jiri Vanek <jvanek at redhat.com> [2012-04-04 12:04]:
> On 04/04/2012 05:58 PM, Deepak Bhole wrote:
> >* Jiri Vanek<jvanek at redhat.com>  [2012-04-04 11:55]:
> >>...snip...
> >>>>>>
> >>>
> >>>
> >>>How about creating a cert, importing it and then signing everything with that
> >>>cert?
> >>>
> >>
> >>Applet is then not asking user anymore???
> >>
> >>If this is true than this is granzgenial:)
> >>
> >>It will need some logic to import the certs to browser, but it will
> >>be needed anyway (see http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-March/017799.html
> >>for more about browser detection)
> >>
> >
> >If you choose to always trust it, yes it shouldn't ask any more.
> 
> hmmm... Can be much  harder then to control this fully-automatically.
> (means create certificate during make is easy, sign all stuff with
> this certificate is easy, import  certificate to browsers should be
> also easy (just cp I believe), force the browser to force this new
> certificate without prompt can be however impossible :( )
> If it is possible  to accept it just oncetimes for all
> future-generated certificates - it will do the job as well.
>

Right, so create a cert, sign a jar with it, and manually start the
browser and go to an applet with that jar. You will get a prompt and
choose to always trust it.

>From there on, anything signed by that cert should always be trusted.
 
> I would like to avoid one static certificate which have to be refreshed each .. some times...
> 

Why is that? You would only be accepting/always trusting it locally for
one specific user.

Cheers,
Deepak


From ddadacha at redhat.com  Wed Apr  4 09:12:08 2012
From: ddadacha at redhat.com (Danesh Dadachanji)
Date: Wed, 04 Apr 2012 12:12:08 -0400
Subject: Fwd: Re: [rfc][icedtea-web] reproducer for PR905
In-Reply-To: <20120404154314.GF23765@redhat.com>
References: <4F7C4F16.3000802@redhat.com> <4F7C5DC1.2030502@redhat.com>
	<4F7C6B50.1050802@redhat.com> <20120404154314.GF23765@redhat.com>
Message-ID: <4F7C72D8.4010803@redhat.com>



On 04/04/12 11:43 AM, Deepak Bhole wrote:
> * Danesh Dadachanji<ddadacha at redhat.com>  [2012-04-04 11:40]:
>> Adding CCs.
>>
>> Cheers,
>> Danesh
>>
>> On 04/04/12 10:42 AM, Jiri Vanek wrote:
>>> uups. Looks Like I have forgot to cc distro-pkg. Please reply to this one.
>>>
>>> -------- Original Message --------
>>> Subject: Re: [rfc][icedtea-web] reproducer for PR905
>>> Date: Wed, 04 Apr 2012 15:39:34 +0200
>>> From: Jiri Vanek<jvanek at redhat.com>
>>> To: Danesh Dadachanji<ddadacha at redhat.com>, Pavel Tisnovsky<ptisnovs at redhat.com>
>>>
>>> On 04/03/2012 11:48 PM, Danesh Dadachanji wrote:
>>>
>>> I have cc also Pavel and Omair because -XtrustAll for applets done wrong can be quite serious.
>>>
>>>> Hi Jiri,
>>>>
>>>> On 26/03/12 12:55 PM, Jiri Vanek wrote:
>>>>> Hi all!
>>>>>
>>>>> This reproducer is representing pr905 behaviour. All the tests except
>>>>> signed jar with parametrised archive are passing, which is correct, and
>>>>> the failing test is representing the issue.
>>>>>
>>>>
>>>> Great job, thanks a lot for doing this! Please see comments below.
>>>>
>>>>> However there is issue which make this reproducer ... useless. All the
>>>>> passing ones are nice, and we can include them (if you agree), but the
>>>>> falling one is signed applet (and simple signed applet test too) in
>>>>> browser. That means that user have to click on "trust" button :-/
>>>>>
>>>>> And I have currently no idea how to forward to plugin something like
>>>>> -Xtrustall :-/
>>>>>
>>>>> My only idea until now is some environment variable which will plugin
>>>>> forward to netx like Xtrustall. However - I have very strong feelings
>>>>> that this can be bloody security hole.
>>>>
>>>> That definitely sounds like a bad security flaw. We need to setup something that user chooses to
>>>> flag at runtime themselves (each time possibly), similarly to explicitly passing -Xtrustall to
>>>> javaws. However, I'm not sure of any way that can do this securely. =(
>>>>
>>>> One option off the top of my head, _just for testing_, might be to have a custom build flag for
>>> This will be probably the only way. But I dont like it:(
>>> I like also the way via itweb-settings, especially when it will be possible via commandline, but it
>>> looks wrong in same way as environment variable.
>>>> icedtea-web. If we pass it in when building (something like --build-for-testing), it could patch
>>>> some of the code to skip the security checks? I'm not sure how suitable this would be though because
>>>> it is modifying the code, no matter how small the modification is. =)
>>>>
>>>>> (definietly is in windows, where you can use activeX to inject
>>>>> environment variable imho)
>>>>>
>>>>> So what do you think about the reproducer. Have it sense to push it
>>>>> without signed-applet-in-browser tests?
>>>>>
>>>>
>>>> Firstly, I don't think this test should be pushed until the fix to PR905 is going into HEAD. I don't
>>> IMHO failing tests representing issue SHOULD be pushed. Omair have temporarily suspended his effort
>>> to ignore failing tests.
>>>> really see why having it in before hand is useful considering the issue is happening regardless, it
>>>> may also scare off devs from running tests even more. =( Would you prefer to have it in before hand?
>>> Definitely O:)
>>> But there is the issue with necessary click right now:-/
>>> Without signed-parametrized applet they have just small reason.
>>> I'm for:
>>> to push the parts which are passing
>>> to push the signed applet
>>> to push failing test
>>> BUT to disable last two which are failing due to necessary click:(
>>>>
>>>> Secondly, regarding the applet-in-browser tests, I think we should keep them there but disable them
>>>> until they can actually pass. Let's try to follow what was discussed in this email[1]. See my
>>>> comments on AppletTestSigned below, they are similar.
>>>>
>>>>> For future - any ideas how to create automated tests for signed applets
>>>>> in browser? (without awt robot)
>>>>>
>>>>
>>>> Another idea could be to store some option (securely) accessible via itweb-settings..something like
>>>> a checkbox for "Trust all applets run in the plugin" and then set this up properly on the test
>>>> machine. I am again unclear as to how we would do this in a way that prevents outsiders from
>>>> modifying the file that stores this flag on the FS. Do you know of any way in which we could save
>>> hmm... some file which can just root modify, and to read it for -XtrustAll? hmm.. this can work!
>>> I believe this setting should be held out of itweb-settings.. What about ~/.icedtea ? But probably
>>> some location where just root can write will be better. As this is intended just for testing
>>> reasons, I'm for direct /etc.
>>>> this "setting"? This does go against what I said above where this should be something specified at
>>>> runtime of each applet but just throwing it out there. =) I suppose figuring this out would help us
>>>> set something similar like an environment variable too though...
>>>>
>>>> Some more comments in-line.
>>>>
>>>>> +2012-03-26 Jiri Vanek<jvanek at redhat.com>
>>>>
>>>> 2 spaces between Last name and<email>  please.
>>>>
>>>>> +
>>>>> + Added tests for PR905 - parameters in jnlp/html application/applet resources
>>>>> + * tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.html:
>>>>> + html file for lunching signed applet
>>>>> + * tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.jnlp:
>>>>> + jnlp fiel for lunched signed applet
>>>>
>>>> s/fiel/file
>>> O:)
>>>>
>>>>> + * tests/jnlp_tests/signed/AppletTestSigned/srcs/AppletTestSigned.java
>>>>> + body of signed applet
>>>>> + * tests/jnlp_tests/signed/AppletTestSigned/testcases/AppletTestSignedTests.java:
>>>>> + (AppletTestSignedTest) testing method to launch signed applet in javaws
>>>>> + (AppletTestSignedFirefoxTest) testing method to launch signed applet in
>>>>> + browser
>>>>
>>>> I think this can be a separate changeset that can be pushed. Just handle the one that is meant to
>>>> fail appropriately. I think the resolution from the email thread[1] was to disable them and make
>>>> bugs for them (for now at least). Could you go through the changes mentioned below that affect
>>>> AppletTestSigned and post a separate review please? Thanks!
>>>
>>> Yes (definitely :) ). But have no sense unless signed applets can be run automaticaly or as I told
>>> above.
>>>>
>
>
> How about creating a cert, importing it and then signing everything with that
> cert?
>

+1, can't believe we didn't think of this before! We don't necessarily need to even create a new cert, the jar's signer is made at 
runtime so all that is needed is adding it to the trusted keystore.

However, since all reproducers are signed by the same cert, that might not be ideal depending on what others are meant to be testing. 
I'm not sure if any use the denial of trust as a test. If so, then another cert would be best.

Cheers,
Danesh


From ddadacha at redhat.com  Wed Apr  4 09:16:55 2012
From: ddadacha at redhat.com (Danesh Dadachanji)
Date: Wed, 04 Apr 2012 12:16:55 -0400
Subject: Fwd: Re: [rfc][icedtea-web] reproducer for PR905
In-Reply-To: <4F7C7147.9010707@redhat.com>
References: <4F7C4F16.3000802@redhat.com> <4F7C5DC1.2030502@redhat.com>
	<4F7C6B50.1050802@redhat.com> <20120404154314.GF23765@redhat.com>
	<4F7C6F2E.8080109@redhat.com> <20120404155853.GH23765@redhat.com>
	<4F7C7147.9010707@redhat.com>
Message-ID: <4F7C73F7.40808@redhat.com>



On 04/04/12 12:05 PM, Jiri Vanek wrote:
> On 04/04/2012 05:58 PM, Deepak Bhole wrote:
>> * Jiri Vanek<jvanek at redhat.com> [2012-04-04 11:55]:
>>> ...snip...
>>>>>>>
>>>>
>>>>
>>>> How about creating a cert, importing it and then signing everything with that
>>>> cert?
>>>>
>>>
>>> Applet is then not asking user anymore???
>>>
>>> If this is true than this is granzgenial:)
>>>
>>> It will need some logic to import the certs to browser, but it will
>>> be needed anyway (see http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-March/017799.html
>>> for more about browser detection)
>>>
>>
>> If you choose to always trust it, yes it shouldn't ask any more.
>
> hmmm... Can be much harder then to control this fully-automatically.
> (means create certificate during make is easy, sign all stuff with this certificate is easy, import certificate to browsers should be
> also easy (just cp I believe), force the browser to force this new certificate without prompt can be however impossible :( )
> If it is possible to accept it just oncetimes for all future-generated certificates - it will do the job as well.
>

Can't you just add it to the keystore? That's what "Always Trust" does anyway IIRC.

> I would like to avoid one static certificate which have to be refreshed each .. some times...
>
>
>>
>> Cheers,
>> Deepak
>


From jvanek at redhat.com  Wed Apr  4 09:19:11 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Wed, 04 Apr 2012 18:19:11 +0200
Subject: Fwd: Re: [rfc][icedtea-web] reproducer for PR905
In-Reply-To: <4F7C73F7.40808@redhat.com>
References: <4F7C4F16.3000802@redhat.com> <4F7C5DC1.2030502@redhat.com>
	<4F7C6B50.1050802@redhat.com> <20120404154314.GF23765@redhat.com>
	<4F7C6F2E.8080109@redhat.com> <20120404155853.GH23765@redhat.com>
	<4F7C7147.9010707@redhat.com> <4F7C73F7.40808@redhat.com>
Message-ID: <4F7C747F.6010706@redhat.com>

On 04/04/2012 06:16 PM, Danesh Dadachanji wrote:
>
>
> On 04/04/12 12:05 PM, Jiri Vanek wrote:
>> On 04/04/2012 05:58 PM, Deepak Bhole wrote:
>>> * Jiri Vanek<jvanek at redhat.com> [2012-04-04 11:55]:
>>>> ...snip...
>>>>>>>>
>>>>>
>>>>>
>>>>> How about creating a cert, importing it and then signing everything with that
>>>>> cert?
>>>>>
>>>>
>>>> Applet is then not asking user anymore???
>>>>
>>>> If this is true than this is granzgenial:)
>>>>
>>>> It will need some logic to import the certs to browser, but it will
>>>> be needed anyway (see http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-March/017799.html
>>>> for more about browser detection)
>>>>
>>>
>>> If you choose to always trust it, yes it shouldn't ask any more.
>>
>> hmmm... Can be much harder then to control this fully-automatically.
>> (means create certificate during make is easy, sign all stuff with this certificate is easy,
>> import certificate to browsers should be
>> also easy (just cp I believe), force the browser to force this new certificate without prompt can
>> be however impossible :( )
>> If it is possible to accept it just oncetimes for all future-generated certificates - it will do
>> the job as well.
>>
>
> Can't you just add it to the keystore? That's what "Always Trust" does anyway IIRC.
>

Well it will solve the issue pretty easy!
Now just to try it:)

>> I would like to avoid one static certificate which have to be refreshed each .. some times...
>>
>>
>>>
>>> Cheers,
>>> Deepak
>>



From dbhole at redhat.com  Wed Apr  4 09:20:31 2012
From: dbhole at redhat.com (Deepak Bhole)
Date: Wed, 4 Apr 2012 12:20:31 -0400
Subject: Fwd: Re: [rfc][icedtea-web] reproducer for PR905
In-Reply-To: <4F7C73F7.40808@redhat.com>
References: <4F7C4F16.3000802@redhat.com> <4F7C5DC1.2030502@redhat.com>
	<4F7C6B50.1050802@redhat.com> <20120404154314.GF23765@redhat.com>
	<4F7C6F2E.8080109@redhat.com> <20120404155853.GH23765@redhat.com>
	<4F7C7147.9010707@redhat.com> <4F7C73F7.40808@redhat.com>
Message-ID: <20120404162030.GL23765@redhat.com>

* Danesh Dadachanji <ddadacha at redhat.com> [2012-04-04 12:16]:
> 
> 
> On 04/04/12 12:05 PM, Jiri Vanek wrote:
> >On 04/04/2012 05:58 PM, Deepak Bhole wrote:
> >>* Jiri Vanek<jvanek at redhat.com> [2012-04-04 11:55]:
> >>>...snip...
> >>>>>>>
> >>>>
> >>>>
> >>>>How about creating a cert, importing it and then signing everything with that
> >>>>cert?
> >>>>
> >>>
> >>>Applet is then not asking user anymore???
> >>>
> >>>If this is true than this is granzgenial:)
> >>>
> >>>It will need some logic to import the certs to browser, but it will
> >>>be needed anyway (see http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-March/017799.html
> >>>for more about browser detection)
> >>>
> >>
> >>If you choose to always trust it, yes it shouldn't ask any more.
> >
> >hmmm... Can be much harder then to control this fully-automatically.
> >(means create certificate during make is easy, sign all stuff with this certificate is easy, import certificate to browsers should be
> >also easy (just cp I believe), force the browser to force this new certificate without prompt can be however impossible :( )
> >If it is possible to accept it just oncetimes for all future-generated certificates - it will do the job as well.
> >
> 
> Can't you just add it to the keystore? That's what "Always Trust" does anyway IIRC.
> 

Yep, that will have the same effect.

Deepak


From jvanek at redhat.com  Wed Apr  4 09:26:20 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Wed, 04 Apr 2012 18:26:20 +0200
Subject: [RFC][icedtea-web] fixes to reproducer engine
In-Reply-To: <4F6B7C1C.3060408@redhat.com>
References: <4F69E3AF.6020102@redhat.com> <20120322140437.GL6489@redhat.com>
	<4F6B7C1C.3060408@redhat.com>
Message-ID: <4F7C762C.5090703@redhat.com>

On 03/22/2012 08:23 PM, Jiri Vanek wrote:
> On 03/22/2012 03:04 PM, Deepak Bhole wrote:
>> * Jiri Vanek<jvanek at redhat.com> [2012-03-21 10:22]:
>>> Hi!
>>>
>>> As I wrote yesterday, I have found some bugs inside jnlp main
>>> engine. This patch is fixing them, and I would like to push it to
>>> head and 1.2 (with minor changes).
>>>
>>> Any comments?
>>>
>>
>> Hi Jiri,
>>
>> Can you please repost with indentations fixed? e.g.:
>
...snip...

Fixed typos.. I hope. Thanx for patience.

J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fixesToJnlpReproducersEngine4.diff
Type: text/x-patch
Size: 17636 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120404/05d3381b/fixesToJnlpReproducersEngine4.diff 

From dbhole at redhat.com  Wed Apr  4 10:19:05 2012
From: dbhole at redhat.com (Deepak Bhole)
Date: Wed, 4 Apr 2012 13:19:05 -0400
Subject: [RFC][icedtea-web] fixes to reproducer engine
In-Reply-To: <4F7C762C.5090703@redhat.com>
References: <4F69E3AF.6020102@redhat.com> <20120322140437.GL6489@redhat.com>
	<4F6B7C1C.3060408@redhat.com> <4F7C762C.5090703@redhat.com>
Message-ID: <20120404171905.GM23765@redhat.com>

* Jiri Vanek <jvanek at redhat.com> [2012-04-04 12:25]:
> On 03/22/2012 08:23 PM, Jiri Vanek wrote:
> >On 03/22/2012 03:04 PM, Deepak Bhole wrote:
> >>* Jiri Vanek<jvanek at redhat.com> [2012-03-21 10:22]:
> >>>Hi!
> >>>
> >>>As I wrote yesterday, I have found some bugs inside jnlp main
> >>>engine. This patch is fixing them, and I would like to push it to
> >>>head and 1.2 (with minor changes).
> >>>
> >>>Any comments?
> >>>
> >>
> >>Hi Jiri,
> >>
> >>Can you please repost with indentations fixed? e.g.:
> >
> ...snip...
> 
> Fixed typos.. I hope. Thanx for patience.


Hi Jiri,

Looks good! OK for HEAD and 1.2 (if needed there).

Cheers,
Deepak

> 
> J.

> diff -r 14284e2041de ChangeLog
> --- a/ChangeLog	Thu Mar 22 13:12:44 2012 -0400
> +++ b/ChangeLog	Tue Mar 27 13:00:31 2012 +0200
> @@ -1,3 +1,20 @@
> +2012-03-22  Jiri Vanek <jvanek at redhat.com>
> +
> +	Fixing issue when process was not launched at all and when was killed but
> +	left behind living/hanging, fixing mime-types
> +	* tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java:
> +	(getContentOfStream) this method overloaded with possibility to specify
> +	encoding (I needed to set it to ASCII in one test)
> +	(deadlyException) field introduced in ThreadedProcess to record exception
> +	caused by impassibility of launching the process. And so process have
> +	been null without any sign why.
> +	(TinyHttpdImpl) now correctly returns known mime types
> +	(ProcessAssasin) can now skip or smoothly (and finally correctly)
> +	destroy its process, and all his logging messages were done null-proof
> +	(as deadlyException now allows)
> +	Asynchronous (ContentReader) have been silenced when complaining about 
> +	closed streams by Assassin.
> +
>  2012-03-21  Omair Majid  <omajid at redhat.com>
>  
>  	* tests/netx/unit/net/sourceforge/jnlp/JNLPMatcherTest.java
> diff -r 14284e2041de tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java
> --- a/tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java	Thu Mar 22 13:12:44 2012 -0400
> +++ b/tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java	Tue Mar 27 13:00:31 2012 +0200
> @@ -254,7 +254,7 @@
>  
>      @Test
>      public void testsProcessResultFiltering() throws Exception {
> -        ProcessResult pn = new ProcessResult(null, null, null, true, 0);
> +        ProcessResult pn = new ProcessResult(null, null, null, true, 0, null);
>          Assert.assertNull(pn.notFilteredStdout);
>          Assert.assertNull(pn.stdout);
>          Assert.assertNull(pn.stderr);
> @@ -273,12 +273,12 @@
>                  "test stage 1\n"
>                  + "test stage 2\n"
>                  + "test stage 3\n";
> -        ProcessResult p2 = new ProcessResult(fakeOut2, fakeOut2, null, true, 0);
> +        ProcessResult p2 = new ProcessResult(fakeOut2, fakeOut2, null, true, 0, null);
>          Assert.assertEquals(p2.notFilteredStdout, fakeOut2);
>          Assert.assertEquals(p2.stdout, filteredOut2);
>          Assert.assertEquals(p2.stderr, fakeOut2);
>          fakeOut2+="\n";
> -        p2 = new ProcessResult(fakeOut2, fakeOut2, null, true, 0);
> +        p2 = new ProcessResult(fakeOut2, fakeOut2, null, true, 0, null);
>          Assert.assertEquals(p2.notFilteredStdout, fakeOut2);
>          Assert.assertEquals(p2.stdout, filteredOut2);
>          Assert.assertEquals(p2.stderr, fakeOut2);
> @@ -300,13 +300,13 @@
>                  + "test stage 2\n"
>                  + "test stage 3\n"
>                  + "test ends";
> -        ProcessResult p = new ProcessResult(fakeOut, fakeOut, null, true, 0);
> +        ProcessResult p = new ProcessResult(fakeOut, fakeOut, null, true, 0, null);
>          Assert.assertEquals(p.notFilteredStdout, fakeOut);
>          Assert.assertEquals(p.stdout, filteredOut);
>          Assert.assertEquals(p.stderr, fakeOut);
>          fakeOut+="\n";
>          filteredOut+="\n";
> -        p = new ProcessResult(fakeOut, fakeOut, null, true, 0);
> +        p = new ProcessResult(fakeOut, fakeOut, null, true, 0, null);
>          Assert.assertEquals(p.notFilteredStdout, fakeOut);
>          Assert.assertEquals(p.stdout, filteredOut);
>          Assert.assertEquals(p.stderr, fakeOut);
> @@ -473,9 +473,9 @@
>       * @return stream as string
>       * @throws IOException if connection cant be established or resource do not exists
>       */
> -    public static String getContentOfStream(InputStream is) throws IOException {
> +    public static String getContentOfStream(InputStream is,String encoding) throws IOException {
>          try {
> -            BufferedReader br = new BufferedReader(new InputStreamReader(is, "UTF-8"));
> +            BufferedReader br = new BufferedReader(new InputStreamReader(is, encoding));
>              StringBuilder sb = new StringBuilder();
>              while (true) {
>                  String s = br.readLine();
> @@ -493,6 +493,18 @@
>      }
>  
>      /**
> +     * utility method which can read from any stream as one long String
> +     *
> +     * @param input stream
> +     * @return stream as string
> +     * @throws IOException if connection cant be established or resource do not exists
> +     */
> +    public static String getContentOfStream(InputStream is) throws IOException {
> +        return getContentOfStream(is, "UTF-8");
> +
> +    }
> +
> +    /**
>       * utility method which can read bytes of resource from any url
>       * 
>       * @param resource to be located on any url
> @@ -703,9 +715,13 @@
>          ProcessAssasin pa = new ProcessAssasin(t, PROCESS_TIMEOUT);
>          pa.start();
>          t.start();
> -        while (t.getP() == null) {
> +        while (t.getP() == null && t.deadlyException == null) {
>              Thread.sleep(100);
>          }
> +        if (t.deadlyException != null) {
> +            pa.setCanRun(false);
> +            return new ProcessResult("", "", null, true, Integer.MIN_VALUE, t.deadlyException);
> +        }
>          ContentReader crs = new ContentReader(t.getP().getInputStream(),stdoutl);
>          ContentReader cre = new ContentReader(t.getP().getErrorStream(),stderrl);
>  
> @@ -719,10 +735,14 @@
>          while (t.isRunning()) {
>              Thread.sleep(100);
>          }
> +
> +        while (!t.isDestoyed()) {
> +            Thread.sleep(100);
> +        }
>          pa.setCanRun(false);
>          // System.out.println(t.getP().exitValue()); when process is killed, this throws exception
>  
> -        return new ProcessResult(crs.getContent(), cre.getContent(), t.getP(), pa.wasTerminated(), t.getExitCode());
> +        return new ProcessResult(crs.getContent(), cre.getContent(), t.getP(), pa.wasTerminated(), t.getExitCode(), null);
>      }
>  
>      /**
> @@ -737,6 +757,20 @@
>          Integer exitCode;
>          Boolean running;
>          File dir;
> +        Throwable deadlyException = null;
> +        /*
> +         * before removing this "useless" variable
> +         * check DeadLockTestTest.testDeadLockTestTerminated2
> +         */
> +        private boolean destoyed = false;
> +
> +        public boolean isDestoyed() {
> +            return destoyed;
> +        }
> +
> +        public void setDestoyed(boolean destoyed) {
> +            this.destoyed = destoyed;
> +        }
>  
>          public Boolean isRunning() {
>              return running;
> @@ -785,13 +819,21 @@
>                  }else{
>                      p = r.exec(args.toArray(new String[0]),new String[0], dir);
>                  }
> -                exitCode = p.waitFor();
> -                Thread.sleep(500);//this is giving to fastly done proecesses's e/o readers time to read all. I would like to know better solution :-/
> +                try {
> +                    exitCode = p.waitFor();
> +                    Thread.sleep(500);//this is giving to fastly done proecesses's e/o readers time to read all. I would like to know better solution :-/
> +                } finally {
> +                    destoyed = true;
> +                }
>              } catch (Exception ex) {
>                  if (ex instanceof InterruptedException) {
>                      //add to the set of terminated threadedproceses
> +                    deadlyException = ex;
>                      terminated.add(this);
>                  } else {
> +                    //happens when nonexisting process is launched, is causing p null!
> +                    terminated.add(this);
> +                    deadlyException = ex;
>                      throw new RuntimeException(ex);
>                  }
>              } finally {
> @@ -937,8 +979,17 @@
>                                  byte[] b = new byte[l];
>                                  FileInputStream f = new FileInputStream(pp);
>                                  f.read(b);
> +                                String content = "";
> +                                String ct = "Content-Type: ";
> +                                if (p.toLowerCase().endsWith(".jnlp")) {
> +                                    content = ct + "application/x-java-jnlp-file\n";
> +                                } else if (p.toLowerCase().endsWith(".html")) {
> +                                    content = ct + "text/html\n";
> +                                } else if (p.toLowerCase().endsWith(".jar")) {
> +                                    content = ct + "application/x-jar\n";
> +                                }
>                                  o.writeBytes("HTTP/1.0 200 OK\nConten"
> -                                        + "t-Length:" + l + "\n\n");
> +                                        + "t-Length:" + l + "\n" + content + "\n");
>                                  if (op.startsWith(XSX)){
>                                      byte[][] bb=ServerAccess.splitArray(b,10);
>                                      for (int j = 0; j < bb.length; j++) {
> @@ -1061,6 +1112,13 @@
>          //false == is disabled:(
>          private boolean canRun = true;
>          private boolean wasTerminated = false;
> +        /**
> +         * if this is true, then process is not destroyed after timeout, but just left to its own destiny.
> +         * Its stdout/err is no longer recorded, and it is leaking system resources until it dies by itself
> +         * The contorl is returned to main thread with all informations recorded  untill now.
> +         * You will be able to listen to std out from listeners still
> +         */
> +        private boolean skipInstedOfDesroy = false;
>  
>          /**
>           *
> @@ -1074,9 +1132,25 @@
>  
>          }
>  
> +        public ProcessAssasin(ThreadedProcess p, long timeout, boolean skipInstedOfDesroy) {
> +            this.p = (p);
> +            this.timeout = timeout;
> +            this.skipInstedOfDesroy = skipInstedOfDesroy;
> +
> +
> +        }
> +
>          public void setCanRun(boolean canRun) {
>              this.canRun = canRun;
> -            System.err.println("Stopping assasin for" + p.toString() + " " + p.getP().toString() + " " + p.getCommandLine() + ": ");
> +            if (p != null) {
> +                if (p.getP() != null) {
> +                    System.err.println("Stopping assassin for" + p.toString() + " " + p.getP().toString() + " " + p.getCommandLine() + ": ");
> +                } else {
> +                    System.err.println("Stopping assassin for" + p.toString() + " " + p.getCommandLine() + ": ");
> +                }
> +            } else {
> +                System.err.println("Stopping assassin for null job: ");
> +            }
>              System.err.flush();
>          }
>  
> @@ -1088,6 +1162,14 @@
>              return wasTerminated;
>          }
>  
> +        public void setSkipInstedOfDesroy(boolean skipInstedOfDesroy) {
> +            this.skipInstedOfDesroy = skipInstedOfDesroy;
> +        }
> +
> +        public boolean isSkipInstedOfDesroy() {
> +            return skipInstedOfDesroy;
> +        }
> +
>          @Override
>          public void run() {
>  
> @@ -1099,17 +1181,44 @@
>                      //System.out.println(time - startTime);
>                      //System.out.println((time - startTime) > timeout);
>                      if ((time - startTime) > timeout) {
> -                        System.err.println("Timeouted " + p.toString() + " " + p.getP().toString() + " .. killing " + p.getCommandLine() + ": ");
> -                        System.err.flush();
> -                        wasTerminated = true;
> -                        p.interrupt();
> -                        while (!terminated.contains(p)) {
> -                            Thread.sleep(100);
> +                        try {
> +                            if (p != null) {
> +                                if (p.getP() != null) {
> +                                    System.err.println("Timed out " + p.toString() + " " + p.getP().toString() + " .. killing " + p.getCommandLine() + ": ");
> +                                } else {
> +                                    System.err.println("Timed out " + p.toString() + " " + "null  .. killing " + p.getCommandLine() + ": ");
> +                                }
> +                                System.err.flush();
> +                                wasTerminated = true;
> +                                p.interrupt();
> +                                while (!terminated.contains(p)) {
> +                                    Thread.sleep(100);
> +                                }
> +                                if (p.getP() != null) {
> +                                    try {
> +                                        if (!skipInstedOfDesroy) {
> +                                            p.getP().destroy();
> +                                        }
> +                                    } catch (Throwable ex) {
> +                                        if (p.deadlyException == null) {
> +                                            p.deadlyException = ex;
> +                                        }
> +                                        ex.printStackTrace();
> +                                    }
> +                                }
> +                                if (p.getP() != null) {
> +                                    System.err.println("Timed out " + p.toString() + " " + p.getP().toString() + " .. killed " + p.getCommandLine());
> +                                } else {
> +                                    System.err.println("Timed out " + p.toString() + " null  .. killed " + p.getCommandLine());
> +                                }
> +                                System.err.flush();
> +                            } else {
> +                                System.err.println("Timed out null job");
> +                            }
> +                            break;
> +                        } finally {
> +                            p.setDestoyed(true);
>                          }
> -                        //p.p.destroy()??
> -                        System.err.println("Timeouted " + p.toString() + " " + p.getP().toString() + " .. killed " + p.getCommandLine());
> -                        System.err.flush();
> -                        break;
>  
>  
>                      }
> @@ -1118,7 +1227,15 @@
>                      ex.printStackTrace();
>                  }
>              }
> -            System.err.println("assasin for" + p.toString() + " " + p.getP().toString() + " .. done " + p.getCommandLine() + "  termination " + wasTerminated);
> +            if (p != null) {
> +                if (p.getP() != null) {
> +                    System.err.println("assassin for" + p.toString() + " " + p.getP().toString() + " .. done " + p.getCommandLine() + "  termination " + wasTerminated);
> +                } else {
> +                    System.err.println("assassin for" + p.toString() + " null .. done " + p.getCommandLine() + "  termination " + wasTerminated);
> +                }
> +            } else {
> +                System.err.println("assassin for non exisitng job  termination " + wasTerminated);
> +            }
>              System.err.flush();
>          }
>      }
> @@ -1134,8 +1251,12 @@
>          public final Process process;
>          public final Integer returnValue;
>          public final boolean wasTerminated;
> +        /*
> +         * possible exception which caused Process not to be launched
> +         */
> +        public final Throwable deadlyException;
>  
> -        public ProcessResult(String stdout, String stderr, Process process, boolean wasTerminated, Integer r) {
> +        public ProcessResult(String stdout, String stderr, Process process, boolean wasTerminated, Integer r, Throwable deadlyException) {
>              this.notFilteredStdout = stdout;
>              if (stdout == null) {
>                  this.stdout = null;
> @@ -1146,6 +1267,7 @@
>              this.process = process;
>              this.wasTerminated = wasTerminated;
>              this.returnValue = r;
> +            this.deadlyException = deadlyException;
>          }
>      }
>  
> @@ -1201,26 +1323,34 @@
>          public void run() {
>              try {
>                  Reader br = new InputStreamReader(is, "UTF-8");
> -                StringBuilder line=new StringBuilder();
> +                StringBuilder line = new StringBuilder();
>                  while (true) {
>                      int s = br.read();
>                      if (s < 0) {
> -                        if (line.length()>0 && listener!=null) listener.lineReaded(line.toString());
> +                        if (line.length() > 0 && listener != null) {
> +                            listener.lineReaded(line.toString());
> +                        }
>                          break;
>                      }
> -                    char ch=((char) s);
> +                    char ch = ((char) s);
>                      sb.append(ch);
>                      line.append(ch);
> -                    if (ch=='\n'){
> -                        if (listener!=null) listener.lineReaded(line.toString());
> -                        line=new StringBuilder();
> +                    if (ch == '\n') {
> +                        if (listener != null) {
> +                            listener.lineReaded(line.toString());
> +                        }
> +                        line = new StringBuilder();
>                      }
> -                    if (listener!=null) listener.charReaded(ch);
> +                    if (listener != null) {
> +                        listener.charReaded(ch);
> +                    }
>  
>                  }
>                  //do not want to bother output with terminations
> +                //mostly compaling when assassin kill the process about StreamClosed
>              } catch (Exception ex) {
> -                ex.printStackTrace();
> +                // ex.printStackTrace();
> +                // System.err.flush();
>              } finally {
>                  try {
>                      is.close();
> 



From ddadacha at redhat.com  Wed Apr  4 14:44:01 2012
From: ddadacha at redhat.com (Danesh Dadachanji)
Date: Wed, 04 Apr 2012 17:44:01 -0400
Subject: [RFC][icedtea-web] Rename JarSigner to JarCertVerifier
Message-ID: <4F7CC0A1.4000003@redhat.com>

Hi,

It's been discussed before that JarSigner is a terrible name for the class that does not ever sign jars. The purpose of JarSigner is to 
perform various checks on all the jars passed to the plugin, specifically to go through and verify the jars' signers.

I propose a better name for it be JarCertVerifier. It implements CertVerifier so I think following the trend (similarly to 
HttpsCertVerifier) is a good idea.

I've gone through the codebase and replaced every mention of JarSigner (ignore-case) to the more suitable naming convention.
I noticed that in the security dialog classes, "jarSigner" is the name of many parameters and passed through to the 
constructors/methods. However, the type of all of these params is CertVerifier. I believe icedtea-web only ever uses these classes with 
a CertVerifier object specifically of type JarSigner but it is potentially possible that they could be of another type that implements 
CertVerifier. I do not think it's a good idea to name the params under this assumption/idea so I've renamed them to be more generic as 
certVerifier. The big incentive behind this is that it confuses devs, I know I was thrown off momentarily by 
SecurityDialog.getJarSigner returning an object of type CertVerifier.

I made the changes through Eclipse's Refactor->Rename command so everything was renamed properly. I also ran 'grep -ir jarsigner 
icedtea-web/', the only things that showed up were in Makefile.am, acinclude.m4 and ChangeLog. The autoconf ones are correct in 
remaining as jarsigner as this is referring to the binary jarsigner, not our lovely class.

All unit tests and reproducers that usually pass did.

Any comments? Can I push to HEAD?

Cheers,
Danesh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rename-jar-signer-01.patch
Type: text/x-patch
Size: 17555 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120404/f5293a47/rename-jar-signer-01.patch 

From omajid at redhat.com  Wed Apr  4 15:50:09 2012
From: omajid at redhat.com (Omair Majid)
Date: Wed, 04 Apr 2012 18:50:09 -0400
Subject: [RFC][icedtea-web] Rename JarSigner to JarCertVerifier
In-Reply-To: <4F7CC0A1.4000003@redhat.com>
References: <4F7CC0A1.4000003@redhat.com>
Message-ID: <4F7CD021.1010700@redhat.com>

Hi Danesh,

On 04/04/2012 05:44 PM, Danesh Dadachanji wrote:
> I propose a better name for it be JarCertVerifier. It implements
> CertVerifier so I think following the trend (similarly to
> HttpsCertVerifier) is a good idea.
> 
> Any comments? Can I push to HEAD?

The patch looks good to me.

Cheers,
Omair


From omajid at redhat.com  Wed Apr  4 16:36:23 2012
From: omajid at redhat.com (Omair Majid)
Date: Wed, 04 Apr 2012 19:36:23 -0400
Subject: [RFC][icedtea-web] Unit tests for the new updates to JarSIgner
	(incomplete)
In-Reply-To: <4F7A1037.7060405@redhat.com>
References: <4F7A1037.7060405@redhat.com>
Message-ID: <4F7CDAF7.6090503@redhat.com>

Hi Danesh,

On 04/02/2012 04:46 PM, Danesh Dadachanji wrote:
> I've been working on updating JarSigner to be able to handle multiple
> signers properly. Currently, it mashes and saves all of the signers'
> properties (flags for expired/badly signed/not yet valid) as one. In
> other words, if one signer has expired, all signers are seen by
> IcedTea-Web as expired. If one has signing issues, then they all have
> signing issues. This is definitely not an ideal solution since we're
> telling users that verifiable applications are not verified.
> 
> The attached patch contains a set of unit tests for the (former)
> verifyJar method. I'm going to avoid including the actual code for these
> changes just yet because the entire class isn't fully cleaned up. Here's
> a bit of background info on what I've changed though.
> 
> 
> * What verifyJar should be doing:
> 
> My understanding of the idea behind verifyJar is that it does 2 somewhat
> separate tasks. First, given a jar, iterate over all of its entries. For
> every entry that can be signed, go through the list of signers and see
> if any have issues. If they do, setup the flags accordingly (issues
> could be expiry/bad key usage/not yet valid start date etc). Also, keep
> track of the number of entries each signer has signed, as well as the
> total number of possible signable entries. The second step is going
> through all of the signers after all the entries have been iterated over
> to see if there is a common signer that has signed them all. If there is
> any entry that is not signed but should be, or if there is one entry
> that does not share a common signer between all other entries, then this
> jar is considered UNSIGNED. If all entries (that should be signed) share
> a common signer, then the signer itself is checked. If the signer has
> signing issues, the jar is considered SIGNED_NOT_OKAY, if it has no
> signing issues, the jar is considered SIGNED_OK.
> 

This does make sense to me. Something that sort of jumps out at me is
that these two responsibilities are fairly distinct. It seems like it
might be worth it to split it into two distinct objects, each taking
care of one responsibility. That is, one objects determines if it should
be considered signed or unsigned, and another checks that (if signed)
the signing certificate is good.

> * Summary of my changes to verifyJar:
> 
> I've split verifyJar into 2 methods, all the logic/implementations from
> line 265[1] and onwards is now in a method named verifyJarEntryCerts.
> Here's a quick snippet of its javadoc and method declaration:
> 
>     /**
>      * Checks through all the jar entries for signers, storing all the
> common
>      * ones in the certs hash map.
>      * @param jarHasManifest Whether or not the associated jar has a
> manifest.
>      * @param entries The list of entries in the associated jar.
>      * @return If there is at least one signable entry that is not
> signed by a
>      * common signer, return UNSIGNED. Otherwise every signable entry is
>      * signed by at least one common signer. If the signer has no issues,
>      * return SIGNED_OK. If there are any signing issues, return
> SIGNED_NOT_OK.
>      * @throws Exception Will be thrown if there are issues with entries.
>      */
>     VerifyResult verifyJarEntryCerts(boolean jarHasManifest,
> Vector<JarEntry> entries) throws Exception
> 
> The reason I've split this method up is so that JarSigner can be made
> unit testable. The method verifyJar takes in a jar name and
> creating/commiting one to upstream isn't suitable. Instead, I've created
> an extra helper method that takes in a list of jar entries and tests
> everything the original code tests. The new unit test class then hard
> codes these entries, along with their signers, to make this method
> testable.

Good stuff!

> For the entries' signers, I've created a helper class that creates
> X509Certificate objects with specified domain names/start dates/validity
> periods. This code is essentially taken from
> sun.security.tools.KeyTool#doGenKeyPair (which calls
> KeyTool#doSelfCert), I've removed the bits that aren't needed
> (KeyStore/alias etc) and left the bare minimum that is needed to create
> an X509Certificate. I'm not 100% sure of the copyright header that is
> needed for this class so I used the same one provided by KeyTool from
> here [2] (with s/2011/2012). I would appreciate any insight as to if
> this is correct. =)

IANAL. That said, you should note all the copyright owners. I believe
that would be Oracle (since they own the original code in KeyTool), and
Red Hat (since that's who owns the newer/modified code). Since both
Oracle and Red Hat have licensed the code under GPLv2+Classpath, it
should be okay to replace this version of the header with the one more
commonly used in icedtea-web (they do refer to the same license after all).

> The unit tests themselves are pretty self-explanatory, to save on
> space/repetition, I've kept testing 1 entry and then 3 entries with the
> same scenario under one method (with different asserts). I think this is
> cleanest but am open to criticism! I've covered everything I could think
> of except for the badKeyUsage/badExtendedKeyUsage/badNetscapeCertType
> cases, I have yet to figure out how to setup certs using them. Is there
> any corner case I've missed?
> 
> Comments are very appreciated!

Some more whitespace might be nice (to separate the asserts from the
code that sets up the preconditions and code that tests the object). We
may also want to split off the separate responsibilities into separate
classes. Still, I think it looks fantastic for now. Nicely done!

Cheers,
Omair


From jvanek at icedtea.classpath.org  Thu Apr  5 03:51:58 2012
From: jvanek at icedtea.classpath.org (jvanek at icedtea.classpath.org)
Date: Thu, 05 Apr 2012 10:51:58 +0000
Subject: /hg/icedtea-web: fixed bugs in jnlp testing engine
Message-ID: <hg.16a8b7bfee7d.1333623118.8643924302249223276@icedtea.classpath.org>

changeset 16a8b7bfee7d in /hg/icedtea-web
details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=16a8b7bfee7d
author: Jiri Vanek <jvanek at redhat.com>
date: Thu Apr 05 12:52:22 2012 +0200

	fixed bugs in jnlp testing engine


diffstat:

 ChangeLog                                                          |   17 +
 tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java |  196 ++++++++-
 2 files changed, 180 insertions(+), 33 deletions(-)

diffs (386 lines):

diff -r f85f7c359b71 -r 16a8b7bfee7d ChangeLog
--- a/ChangeLog	Tue Apr 03 16:04:55 2012 -0400
+++ b/ChangeLog	Thu Apr 05 12:52:22 2012 +0200
@@ -1,3 +1,20 @@
+2012-04-05  Jiri Vanek <jvanek at redhat.com>
+
+	Fixing issue when process was not launched at all and when was killed but
+	left behind living/hanging, fixing mime-types
+	* tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java:
+	(getContentOfStream) this method overloaded with possibility to specify
+	encoding (I needed to set it to ASCII in one test)
+	(deadlyException) field introduced in ThreadedProcess to record exception
+	caused by impassibility of launching the process. And so process have
+	been null without any sign why.
+	(TinyHttpdImpl) now correctly returns known mime types
+	(ProcessAssasin) can now skip or smoothly (and finally correctly)
+	destroy its process, and all his logging messages were done null-proof
+	(as deadlyException now allows)
+	Asynchronous (ContentReader) have been silenced when complaining about 
+	closed streams by Assassin.
+
 2012-04-03  Danesh Dadachanji  <ddadacha at redhat.com>
 
 	Change all vendors in JNLP test suite to IcedTea and homepage href's to
diff -r f85f7c359b71 -r 16a8b7bfee7d tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java
--- a/tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java	Tue Apr 03 16:04:55 2012 -0400
+++ b/tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java	Thu Apr 05 12:52:22 2012 +0200
@@ -267,7 +267,7 @@
 
     @Test
     public void testsProcessResultFiltering() throws Exception {
-        ProcessResult pn = new ProcessResult(null, null, null, true, 0);
+        ProcessResult pn = new ProcessResult(null, null, null, true, 0, null);
         Assert.assertNull(pn.notFilteredStdout);
         Assert.assertNull(pn.stdout);
         Assert.assertNull(pn.stderr);
@@ -286,12 +286,12 @@
                 "test stage 1\n"
                 + "test stage 2\n"
                 + "test stage 3\n";
-        ProcessResult p2 = new ProcessResult(fakeOut2, fakeOut2, null, true, 0);
+        ProcessResult p2 = new ProcessResult(fakeOut2, fakeOut2, null, true, 0, null);
         Assert.assertEquals(p2.notFilteredStdout, fakeOut2);
         Assert.assertEquals(p2.stdout, filteredOut2);
         Assert.assertEquals(p2.stderr, fakeOut2);
         fakeOut2+="\n";
-        p2 = new ProcessResult(fakeOut2, fakeOut2, null, true, 0);
+        p2 = new ProcessResult(fakeOut2, fakeOut2, null, true, 0, null);
         Assert.assertEquals(p2.notFilteredStdout, fakeOut2);
         Assert.assertEquals(p2.stdout, filteredOut2);
         Assert.assertEquals(p2.stderr, fakeOut2);
@@ -313,13 +313,13 @@
                 + "test stage 2\n"
                 + "test stage 3\n"
                 + "test ends";
-        ProcessResult p = new ProcessResult(fakeOut, fakeOut, null, true, 0);
+        ProcessResult p = new ProcessResult(fakeOut, fakeOut, null, true, 0, null);
         Assert.assertEquals(p.notFilteredStdout, fakeOut);
         Assert.assertEquals(p.stdout, filteredOut);
         Assert.assertEquals(p.stderr, fakeOut);
         fakeOut+="\n";
         filteredOut+="\n";
-        p = new ProcessResult(fakeOut, fakeOut, null, true, 0);
+        p = new ProcessResult(fakeOut, fakeOut, null, true, 0, null);
         Assert.assertEquals(p.notFilteredStdout, fakeOut);
         Assert.assertEquals(p.stdout, filteredOut);
         Assert.assertEquals(p.stderr, fakeOut);
@@ -486,9 +486,9 @@
      * @return stream as string
      * @throws IOException if connection cant be established or resource do not exists
      */
-    public static String getContentOfStream(InputStream is) throws IOException {
+    public static String getContentOfStream(InputStream is,String encoding) throws IOException {
         try {
-            BufferedReader br = new BufferedReader(new InputStreamReader(is, "UTF-8"));
+            BufferedReader br = new BufferedReader(new InputStreamReader(is, encoding));
             StringBuilder sb = new StringBuilder();
             while (true) {
                 String s = br.readLine();
@@ -506,6 +506,18 @@
     }
 
     /**
+     * utility method which can read from any stream as one long String
+     *
+     * @param input stream
+     * @return stream as string
+     * @throws IOException if connection cant be established or resource do not exists
+     */
+    public static String getContentOfStream(InputStream is) throws IOException {
+        return getContentOfStream(is, "UTF-8");
+
+    }
+
+    /**
      * utility method which can read bytes of resource from any url
      * 
      * @param resource to be located on any url
@@ -716,9 +728,13 @@
         ProcessAssasin pa = new ProcessAssasin(t, PROCESS_TIMEOUT);
         pa.start();
         t.start();
-        while (t.getP() == null) {
+        while (t.getP() == null && t.deadlyException == null) {
             Thread.sleep(100);
         }
+        if (t.deadlyException != null) {
+            pa.setCanRun(false);
+            return new ProcessResult("", "", null, true, Integer.MIN_VALUE, t.deadlyException);
+        }
         ContentReader crs = new ContentReader(t.getP().getInputStream(),stdoutl);
         ContentReader cre = new ContentReader(t.getP().getErrorStream(),stderrl);
 
@@ -732,10 +748,14 @@
         while (t.isRunning()) {
             Thread.sleep(100);
         }
+
+        while (!t.isDestoyed()) {
+            Thread.sleep(100);
+        }
         pa.setCanRun(false);
         // System.out.println(t.getP().exitValue()); when process is killed, this throws exception
 
-        return new ProcessResult(crs.getContent(), cre.getContent(), t.getP(), pa.wasTerminated(), t.getExitCode());
+        return new ProcessResult(crs.getContent(), cre.getContent(), t.getP(), pa.wasTerminated(), t.getExitCode(), null);
     }
 
     /**
@@ -750,6 +770,20 @@
         Integer exitCode;
         Boolean running;
         File dir;
+        Throwable deadlyException = null;
+        /*
+         * before removing this "useless" variable
+         * check DeadLockTestTest.testDeadLockTestTerminated2
+         */
+        private boolean destoyed = false;
+
+        public boolean isDestoyed() {
+            return destoyed;
+        }
+
+        public void setDestoyed(boolean destoyed) {
+            this.destoyed = destoyed;
+        }
 
         public Boolean isRunning() {
             return running;
@@ -798,13 +832,21 @@
                 }else{
                     p = r.exec(args.toArray(new String[0]),new String[0], dir);
                 }
-                exitCode = p.waitFor();
-                Thread.sleep(500);//this is giving to fastly done proecesses's e/o readers time to read all. I would like to know better solution :-/
+                try {
+                    exitCode = p.waitFor();
+                    Thread.sleep(500);//this is giving to fastly done proecesses's e/o readers time to read all. I would like to know better solution :-/
+                } finally {
+                    destoyed = true;
+                }
             } catch (Exception ex) {
                 if (ex instanceof InterruptedException) {
                     //add to the set of terminated threadedproceses
+                    deadlyException = ex;
                     terminated.add(this);
                 } else {
+                    //happens when nonexisting process is launched, is causing p null!
+                    terminated.add(this);
+                    deadlyException = ex;
                     throw new RuntimeException(ex);
                 }
             } finally {
@@ -950,8 +992,17 @@
                                 byte[] b = new byte[l];
                                 FileInputStream f = new FileInputStream(pp);
                                 f.read(b);
+                                String content = "";
+                                String ct = "Content-Type: ";
+                                if (p.toLowerCase().endsWith(".jnlp")) {
+                                    content = ct + "application/x-java-jnlp-file\n";
+                                } else if (p.toLowerCase().endsWith(".html")) {
+                                    content = ct + "text/html\n";
+                                } else if (p.toLowerCase().endsWith(".jar")) {
+                                    content = ct + "application/x-jar\n";
+                                }
                                 o.writeBytes("HTTP/1.0 200 OK\nConten"
-                                        + "t-Length:" + l + "\n\n");
+                                        + "t-Length:" + l + "\n" + content + "\n");
                                 if (op.startsWith(XSX)){
                                     byte[][] bb=ServerAccess.splitArray(b,10);
                                     for (int j = 0; j < bb.length; j++) {
@@ -1074,6 +1125,13 @@
         //false == is disabled:(
         private boolean canRun = true;
         private boolean wasTerminated = false;
+        /**
+         * if this is true, then process is not destroyed after timeout, but just left to its own destiny.
+         * Its stdout/err is no longer recorded, and it is leaking system resources until it dies by itself
+         * The contorl is returned to main thread with all informations recorded  untill now.
+         * You will be able to listen to std out from listeners still
+         */
+        private boolean skipInstedOfDesroy = false;
 
         /**
          *
@@ -1087,9 +1145,25 @@
 
         }
 
+        public ProcessAssasin(ThreadedProcess p, long timeout, boolean skipInstedOfDesroy) {
+            this.p = (p);
+            this.timeout = timeout;
+            this.skipInstedOfDesroy = skipInstedOfDesroy;
+
+
+        }
+
         public void setCanRun(boolean canRun) {
             this.canRun = canRun;
-            System.err.println("Stopping assasin for" + p.toString() + " " + p.getP().toString() + " " + p.getCommandLine() + ": ");
+            if (p != null) {
+                if (p.getP() != null) {
+                    System.err.println("Stopping assassin for" + p.toString() + " " + p.getP().toString() + " " + p.getCommandLine() + ": ");
+                } else {
+                    System.err.println("Stopping assassin for" + p.toString() + " " + p.getCommandLine() + ": ");
+                }
+            } else {
+                System.err.println("Stopping assassin for null job: ");
+            }
             System.err.flush();
         }
 
@@ -1101,6 +1175,14 @@
             return wasTerminated;
         }
 
+        public void setSkipInstedOfDesroy(boolean skipInstedOfDesroy) {
+            this.skipInstedOfDesroy = skipInstedOfDesroy;
+        }
+
+        public boolean isSkipInstedOfDesroy() {
+            return skipInstedOfDesroy;
+        }
+
         @Override
         public void run() {
 
@@ -1112,17 +1194,44 @@
                     //System.out.println(time - startTime);
                     //System.out.println((time - startTime) > timeout);
                     if ((time - startTime) > timeout) {
-                        System.err.println("Timeouted " + p.toString() + " " + p.getP().toString() + " .. killing " + p.getCommandLine() + ": ");
-                        System.err.flush();
-                        wasTerminated = true;
-                        p.interrupt();
-                        while (!terminated.contains(p)) {
-                            Thread.sleep(100);
+                        try {
+                            if (p != null) {
+                                if (p.getP() != null) {
+                                    System.err.println("Timed out " + p.toString() + " " + p.getP().toString() + " .. killing " + p.getCommandLine() + ": ");
+                                } else {
+                                    System.err.println("Timed out " + p.toString() + " " + "null  .. killing " + p.getCommandLine() + ": ");
+                                }
+                                System.err.flush();
+                                wasTerminated = true;
+                                p.interrupt();
+                                while (!terminated.contains(p)) {
+                                    Thread.sleep(100);
+                                }
+                                if (p.getP() != null) {
+                                    try {
+                                        if (!skipInstedOfDesroy) {
+                                            p.getP().destroy();
+                                        }
+                                    } catch (Throwable ex) {
+                                        if (p.deadlyException == null) {
+                                            p.deadlyException = ex;
+                                        }
+                                        ex.printStackTrace();
+                                    }
+                                }
+                                if (p.getP() != null) {
+                                    System.err.println("Timed out " + p.toString() + " " + p.getP().toString() + " .. killed " + p.getCommandLine());
+                                } else {
+                                    System.err.println("Timed out " + p.toString() + " null  .. killed " + p.getCommandLine());
+                                }
+                                System.err.flush();
+                            } else {
+                                System.err.println("Timed out null job");
+                            }
+                            break;
+                        } finally {
+                            p.setDestoyed(true);
                         }
-                        //p.p.destroy()??
-                        System.err.println("Timeouted " + p.toString() + " " + p.getP().toString() + " .. killed " + p.getCommandLine());
-                        System.err.flush();
-                        break;
 
 
                     }
@@ -1131,7 +1240,15 @@
                     ex.printStackTrace();
                 }
             }
-            System.err.println("assasin for" + p.toString() + " " + p.getP().toString() + " .. done " + p.getCommandLine() + "  termination " + wasTerminated);
+            if (p != null) {
+                if (p.getP() != null) {
+                    System.err.println("assassin for" + p.toString() + " " + p.getP().toString() + " .. done " + p.getCommandLine() + "  termination " + wasTerminated);
+                } else {
+                    System.err.println("assassin for" + p.toString() + " null .. done " + p.getCommandLine() + "  termination " + wasTerminated);
+                }
+            } else {
+                System.err.println("assassin for non exisitng job  termination " + wasTerminated);
+            }
             System.err.flush();
         }
     }
@@ -1147,8 +1264,12 @@
         public final Process process;
         public final Integer returnValue;
         public final boolean wasTerminated;
+        /*
+         * possible exception which caused Process not to be launched
+         */
+        public final Throwable deadlyException;
 
-        public ProcessResult(String stdout, String stderr, Process process, boolean wasTerminated, Integer r) {
+        public ProcessResult(String stdout, String stderr, Process process, boolean wasTerminated, Integer r, Throwable deadlyException) {
             this.notFilteredStdout = stdout;
             if (stdout == null) {
                 this.stdout = null;
@@ -1159,6 +1280,7 @@
             this.process = process;
             this.wasTerminated = wasTerminated;
             this.returnValue = r;
+            this.deadlyException = deadlyException;
         }
     }
 
@@ -1214,26 +1336,34 @@
         public void run() {
             try {
                 Reader br = new InputStreamReader(is, "UTF-8");
-                StringBuilder line=new StringBuilder();
+                StringBuilder line = new StringBuilder();
                 while (true) {
                     int s = br.read();
                     if (s < 0) {
-                        if (line.length()>0 && listener!=null) listener.lineReaded(line.toString());
+                        if (line.length() > 0 && listener != null) {
+                            listener.lineReaded(line.toString());
+                        }
                         break;
                     }
-                    char ch=((char) s);
+                    char ch = ((char) s);
                     sb.append(ch);
                     line.append(ch);
-                    if (ch=='\n'){
-                        if (listener!=null) listener.lineReaded(line.toString());
-                        line=new StringBuilder();
+                    if (ch == '\n') {
+                        if (listener != null) {
+                            listener.lineReaded(line.toString());
+                        }
+                        line = new StringBuilder();
                     }
-                    if (listener!=null) listener.charReaded(ch);
+                    if (listener != null) {
+                        listener.charReaded(ch);
+                    }
 
                 }
                 //do not want to bother output with terminations
+                //mostly compaling when assassin kill the process about StreamClosed
             } catch (Exception ex) {
-                ex.printStackTrace();
+                // ex.printStackTrace();
+                // System.err.flush();
             } finally {
                 try {
                     is.close();


From jvanek at icedtea.classpath.org  Thu Apr  5 03:52:07 2012
From: jvanek at icedtea.classpath.org (jvanek at icedtea.classpath.org)
Date: Thu, 05 Apr 2012 10:52:07 +0000
Subject: /hg/release/icedtea-web-1.2: fixed bugs in jnlp testing engine
Message-ID: <hg.79b3ded39c1f.1333623127.-5934593987637005768@icedtea.classpath.org>

changeset 79b3ded39c1f in /hg/release/icedtea-web-1.2
details: http://icedtea.classpath.org/hg/release/icedtea-web-1.2?cmd=changeset;node=79b3ded39c1f
author: Jiri Vanek <jvanek at redhat.com>
date: Thu Apr 05 12:52:17 2012 +0200

	fixed bugs in jnlp testing engine


diffstat:

 ChangeLog                                                          |   17 +
 tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java |  174 ++++++++-
 2 files changed, 167 insertions(+), 24 deletions(-)

diffs (353 lines):

diff -r 9c0e0aec8ac8 -r 79b3ded39c1f ChangeLog
--- a/ChangeLog	Mon Apr 02 11:26:17 2012 -0400
+++ b/ChangeLog	Thu Apr 05 12:52:17 2012 +0200
@@ -1,3 +1,20 @@
+2012-04-05  Jiri Vanek <jvanek at redhat.com>
+
+	Fixing issue when process was not launched at all and when was killed but
+	left behind living/hanging, fixing mime-types
+	* tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java:
+	(getContentOfStream) this method overloaded with possibility to specify
+	encoding (I needed to set it to ASCII in one test)
+	(deadlyException) field introduced in ThreadedProcess to record exception
+	caused by impassibility of launching the process. And so process have
+	been null without any sign why.
+	(TinyHttpdImpl) now correctly returns known mime types
+	(ProcessAssasin) can now skip or smoothly (and finally correctly)
+	destroy its process, and all his logging messages were done null-proof
+	(as deadlyException now allows)
+	Asynchronous (ContentReader) have been silenced when complaining about 
+	closed streams by Assassin.
+
 2012-03-30  Danesh Dadachanji  <ddadacha at redhat.com>
 
 	Certificate start dates are not being checked, they are still verified
diff -r 9c0e0aec8ac8 -r 79b3ded39c1f tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java
--- a/tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java	Mon Apr 02 11:26:17 2012 -0400
+++ b/tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java	Thu Apr 05 12:52:17 2012 +0200
@@ -209,7 +209,7 @@
 
     @Test
     public void testsProcessResultFiltering() throws Exception {
-        ProcessResult pn = new ProcessResult(null, null, null, true, 0);
+        ProcessResult pn = new ProcessResult(null, null, null, true, 0, null);
         Assert.assertNull(pn.notFilteredStdout);
         Assert.assertNull(pn.stdout);
         Assert.assertNull(pn.stderr);
@@ -228,12 +228,12 @@
                 "test stage 1\n"
                 + "test stage 2\n"
                 + "test stage 3\n";
-        ProcessResult p2 = new ProcessResult(fakeOut2, fakeOut2, null, true, 0);
+        ProcessResult p2 = new ProcessResult(fakeOut2, fakeOut2, null, true, 0, null);
         Assert.assertEquals(p2.notFilteredStdout, fakeOut2);
         Assert.assertEquals(p2.stdout, filteredOut2);
         Assert.assertEquals(p2.stderr, fakeOut2);
         fakeOut2+="\n";
-        p2 = new ProcessResult(fakeOut2, fakeOut2, null, true, 0);
+        p2 = new ProcessResult(fakeOut2, fakeOut2, null, true, 0, null);
         Assert.assertEquals(p2.notFilteredStdout, fakeOut2);
         Assert.assertEquals(p2.stdout, filteredOut2);
         Assert.assertEquals(p2.stderr, fakeOut2);
@@ -255,13 +255,13 @@
                 + "test stage 2\n"
                 + "test stage 3\n"
                 + "test ends";
-        ProcessResult p = new ProcessResult(fakeOut, fakeOut, null, true, 0);
+        ProcessResult p = new ProcessResult(fakeOut, fakeOut, null, true, 0, null);
         Assert.assertEquals(p.notFilteredStdout, fakeOut);
         Assert.assertEquals(p.stdout, filteredOut);
         Assert.assertEquals(p.stderr, fakeOut);
         fakeOut+="\n";
         filteredOut+="\n";
-        p = new ProcessResult(fakeOut, fakeOut, null, true, 0);
+        p = new ProcessResult(fakeOut, fakeOut, null, true, 0, null);
         Assert.assertEquals(p.notFilteredStdout, fakeOut);
         Assert.assertEquals(p.stdout, filteredOut);
         Assert.assertEquals(p.stderr, fakeOut);
@@ -421,9 +421,9 @@
      * @return stream as string
      * @throws IOException if connection cant be established or resource do not exists
      */
-    public static String getContentOfStream(InputStream is) throws IOException {
+    public static String getContentOfStream(InputStream is,String encoding) throws IOException {
         try {
-            BufferedReader br = new BufferedReader(new InputStreamReader(is, "UTF-8"));
+            BufferedReader br = new BufferedReader(new InputStreamReader(is, encoding));
             StringBuilder sb = new StringBuilder();
             while (true) {
                 String s = br.readLine();
@@ -441,6 +441,18 @@
     }
 
     /**
+     * utility method which can read from any stream as one long String
+     *
+     * @param input stream
+     * @return stream as string
+     * @throws IOException if connection cant be established or resource do not exists
+     */
+    public static String getContentOfStream(InputStream is) throws IOException {
+        return getContentOfStream(is, "UTF-8");
+
+    }
+
+    /**
      * utility method which can read bytes of resource from any url
      * 
      * @param resource to be located on any url
@@ -601,9 +613,13 @@
         ProcessAssasin pa = new ProcessAssasin(t, PROCESS_TIMEOUT);
         pa.start();
         t.start();
-        while (t.getP() == null) {
+        while (t.getP() == null && t.deadlyException == null) {
             Thread.sleep(100);
         }
+        if (t.deadlyException != null) {
+            pa.setCanRun(false);
+            return new ProcessResult("", "", null, true, Integer.MIN_VALUE, t.deadlyException);
+        }
         ContentReader crs = new ContentReader(t.getP().getInputStream());
         ContentReader cre = new ContentReader(t.getP().getErrorStream());
 
@@ -617,10 +633,14 @@
         while (t.isRunning()) {
             Thread.sleep(100);
         }
+
+        while (!t.isDestoyed()) {
+            Thread.sleep(100);
+        }
         pa.setCanRun(false);
         // System.out.println(t.getP().exitValue()); when process is killed, this throws exception
 
-        return new ProcessResult(crs.getContent(), cre.getContent(), t.getP(), pa.wasTerminated(), t.getExitCode());
+        return new ProcessResult(crs.getContent(), cre.getContent(), t.getP(), pa.wasTerminated(), t.getExitCode(), null);
     }
 
     /**
@@ -635,6 +655,20 @@
         Integer exitCode;
         Boolean running;
         File dir;
+        Throwable deadlyException = null;
+        /*
+         * before removing this "useless" variable
+         * check DeadLockTestTest.testDeadLockTestTerminated2
+         */
+        private boolean destoyed = false;
+
+        public boolean isDestoyed() {
+            return destoyed;
+        }
+
+        public void setDestoyed(boolean destoyed) {
+            this.destoyed = destoyed;
+        }
 
         public Boolean isRunning() {
             return running;
@@ -683,12 +717,21 @@
                 }else{
                     p = r.exec(args.toArray(new String[0]),new String[0], dir);
                 }
-                exitCode = p.waitFor();
+                try {
+                    exitCode = p.waitFor();
+                    Thread.sleep(500);//this is giving to fastly done proecesses's e/o readers time to read all. I would like to know better solution :-/
+                } finally {
+                    destoyed = true;
+                }
             } catch (Exception ex) {
                 if (ex instanceof InterruptedException) {
                     //add to the set of terminated threadedproceses
+                    deadlyException = ex;
                     terminated.add(this);
                 } else {
+                    //happens when nonexisting process is launched, is causing p null!
+                    terminated.add(this);
+                    deadlyException = ex;
                     throw new RuntimeException(ex);
                 }
             } finally {
@@ -828,8 +871,17 @@
                                 byte[] b = new byte[l];
                                 FileInputStream f = new FileInputStream(pp);
                                 f.read(b);
+                                String content = "";
+                                String ct = "Content-Type: ";
+                                if (p.toLowerCase().endsWith(".jnlp")) {
+                                    content = ct + "application/x-java-jnlp-file\n";
+                                } else if (p.toLowerCase().endsWith(".html")) {
+                                    content = ct + "text/html\n";
+                                } else if (p.toLowerCase().endsWith(".jar")) {
+                                    content = ct + "application/x-jar\n";
+                                }
                                 o.writeBytes("HTTP/1.0 200 OK\nConten"
-                                        + "t-Length:" + l + "\n\n");
+                                        + "t-Length:" + l + "\n" + content + "\n");
                                 o.write(b, 0, l);
                             }
                         }
@@ -855,6 +907,13 @@
         //false == is disabled:(
         private boolean canRun = true;
         private boolean wasTerminated = false;
+        /**
+         * if this is true, then process is not destroyed after timeout, but just left to its own destiny.
+         * Its stdout/err is no longer recorded, and it is leaking system resources until it dies by itself
+         * The contorl is returned to main thread with all informations recorded  untill now.
+         * You will be able to listen to std out from listeners still
+         */
+        private boolean skipInstedOfDesroy = false;
 
         /**
          *
@@ -868,9 +927,25 @@
 
         }
 
+        public ProcessAssasin(ThreadedProcess p, long timeout, boolean skipInstedOfDesroy) {
+            this.p = (p);
+            this.timeout = timeout;
+            this.skipInstedOfDesroy = skipInstedOfDesroy;
+
+
+        }
+
         public void setCanRun(boolean canRun) {
             this.canRun = canRun;
-            System.err.println("Stopping assasin for" + p.toString() + " " + p.getP().toString() + " " + p.getCommandLine() + ": ");
+            if (p != null) {
+                if (p.getP() != null) {
+                    System.err.println("Stopping assassin for" + p.toString() + " " + p.getP().toString() + " " + p.getCommandLine() + ": ");
+                } else {
+                    System.err.println("Stopping assassin for" + p.toString() + " " + p.getCommandLine() + ": ");
+                }
+            } else {
+                System.err.println("Stopping assassin for null job: ");
+            }
             System.err.flush();
         }
 
@@ -882,6 +957,14 @@
             return wasTerminated;
         }
 
+        public void setSkipInstedOfDesroy(boolean skipInstedOfDesroy) {
+            this.skipInstedOfDesroy = skipInstedOfDesroy;
+        }
+
+        public boolean isSkipInstedOfDesroy() {
+            return skipInstedOfDesroy;
+        }
+
         @Override
         public void run() {
 
@@ -893,16 +976,44 @@
                     //System.out.println(time - startTime);
                     //System.out.println((time - startTime) > timeout);
                     if ((time - startTime) > timeout) {
-                        System.err.println("Timeouted " + p.toString() + " " + p.getP().toString() + " .. killing " + p.getCommandLine() + ": ");
-                        System.err.flush();
-                        wasTerminated = true;
-                        p.interrupt();
-                        while (!terminated.contains(p)) {
-                            Thread.sleep(100);
+                        try {
+                            if (p != null) {
+                                if (p.getP() != null) {
+                                    System.err.println("Timed out " + p.toString() + " " + p.getP().toString() + " .. killing " + p.getCommandLine() + ": ");
+                                } else {
+                                    System.err.println("Timed out " + p.toString() + " " + "null  .. killing " + p.getCommandLine() + ": ");
+                                }
+                                System.err.flush();
+                                wasTerminated = true;
+                                p.interrupt();
+                                while (!terminated.contains(p)) {
+                                    Thread.sleep(100);
+                                }
+                                if (p.getP() != null) {
+                                    try {
+                                        if (!skipInstedOfDesroy) {
+                                            p.getP().destroy();
+                                        }
+                                    } catch (Throwable ex) {
+                                        if (p.deadlyException == null) {
+                                            p.deadlyException = ex;
+                                        }
+                                        ex.printStackTrace();
+                                    }
+                                }
+                                if (p.getP() != null) {
+                                    System.err.println("Timed out " + p.toString() + " " + p.getP().toString() + " .. killed " + p.getCommandLine());
+                                } else {
+                                    System.err.println("Timed out " + p.toString() + " null  .. killed " + p.getCommandLine());
+                                }
+                                System.err.flush();
+                            } else {
+                                System.err.println("Timed out null job");
+                            }
+                            break;
+                        } finally {
+                            p.setDestoyed(true);
                         }
-                        System.err.println("Timeouted " + p.toString() + " " + p.getP().toString() + " .. killed " + p.getCommandLine());
-                        System.err.flush();
-                        break;
 
 
                     }
@@ -911,7 +1022,15 @@
                     ex.printStackTrace();
                 }
             }
-            System.err.println("assasin for" + p.toString() + " " + p.getP().toString() + " .. done " + p.getCommandLine() + "  termination " + wasTerminated);
+            if (p != null) {
+                if (p.getP() != null) {
+                    System.err.println("assassin for" + p.toString() + " " + p.getP().toString() + " .. done " + p.getCommandLine() + "  termination " + wasTerminated);
+                } else {
+                    System.err.println("assassin for" + p.toString() + " null .. done " + p.getCommandLine() + "  termination " + wasTerminated);
+                }
+            } else {
+                System.err.println("assassin for non exisitng job  termination " + wasTerminated);
+            }
             System.err.flush();
         }
     }
@@ -927,8 +1046,12 @@
         public final Process process;
         public final Integer returnValue;
         public final boolean wasTerminated;
+        /*
+         * possible exception which caused Process not to be launched
+         */
+        public final Throwable deadlyException;
 
-        public ProcessResult(String stdout, String stderr, Process process, boolean wasTerminated, Integer r) {
+        public ProcessResult(String stdout, String stderr, Process process, boolean wasTerminated, Integer r, Throwable deadlyException) {
             this.notFilteredStdout = stdout;
             if (stdout == null) {
                 this.stdout = null;
@@ -939,6 +1062,7 @@
             this.process = process;
             this.wasTerminated = wasTerminated;
             this.returnValue = r;
+            this.deadlyException = deadlyException;
         }
     }
 
@@ -991,8 +1115,10 @@
 
                 }
                 //do not want to bother output with terminations
+                //mostly compaling when assassin kill the process about StreamClosed
             } catch (Exception ex) {
-                //ex.printStackTrace();
+                // ex.printStackTrace();
+                // System.err.flush();
             } finally {
                 try {
                     is.close();


From jvanek at redhat.com  Thu Apr  5 05:59:46 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Thu, 05 Apr 2012 14:59:46 +0200
Subject: [RFC] Fix IndexOutOfBoundException because of corrupted entry
	in recently_used file
In-Reply-To: <1333551460.6613.13.camel@localhost.localdomain>
References: <1332938501.1397.15.camel@localhost.localdomain>
	<4F79A620.2090702@redhat.com>
	<1333447622.5010.11.camel@localhost.localdomain>
	<4F7AE134.7080500@redhat.com>
	<1333458882.5010.14.camel@localhost.localdomain>
	<4F7B0E34.7010209@redhat.com>
	<1333551460.6613.13.camel@localhost.localdomain>
Message-ID: <4F7D9742.4010608@redhat.com>

On 04/04/2012 04:57 PM, Thomas Meyer wrote:
> Am Dienstag, den 03.04.2012, 16:50 +0200 schrieb Jiri Vanek:
>> >  Thanx for test! Logic itself is good, but there are two mistakes which causes the test to be not-working.
>> >  See notes inline for them.
> Hi,
>
> I hacked a bit on this today. please have a look at the attached patch.
>
> I moved all the format checks in the CacheLRUWrapper.load() method. that
> is the place were I think they actually belong.
>
> I guess these changes will break the CacheReproducerTest as no more
> LRUExceptions are thrown.
I would like to notice outside world that cache was corrupted. (LruCacheException) 
ex.printStacktrace  can be as good as anything else (and is backward compatible with existing approach.

However to print stacktrace just in debug mode will be probably better idea.
Plus information text I have dared to add.
>
> what do you think about this approach? does this make sense for you?

Yap! I till it excellent. It is also handling multiple launches upon broken cache better then my 
original fix did.
  Although there was an bug in removing item from cache with running iteration  (which was causing 
ConcurrentModificationException)

I have dared to fix this and LruCacheException printing and to include working tests to your 
original patch. This "improved" one is attached.

However still several questions to your original one in-line:
>
> with kind regards
> thomas
>
>
>
>
> check-cache-data.patch
>
>
> diff -r 093896b370d3 Makefile.am
> --- a/Makefile.am	Wed Mar 28 12:08:10 2012 +0200
> +++ b/Makefile.am	Wed Apr 04 16:48:09 2012 +0200
> @@ -565,7 +565,7 @@
>   	cd $(JNLP_TESTS_ENGINE_DIR) ; \
>   	class_names=`cat $(REPRODUCERS_CLASS_NAMES)` ; \
>   	CLASSPATH=$(NETX_DIR)/lib/classes.jar:$(JUNIT_JAR):$(JUNIT_RUNNER_JAR):. \
> -	  $(BOOT_DIR)/bin/java -Dtest.server.dir=$(JNLP_TESTS_SERVER_DEPLOYDIR) -Djavaws.build.bin=$(DESTDIR)$(bindir)/javaws \
> +	  $(BOOT_DIR)/bin/java -Dtest.server.dir=$(JNLP_TESTS_SERVER_DEPLOYDIR) -Djavaws.build.bin=$(DESTDIR)$(bindir)/$(javaws) \
>   	 -Xbootclasspath:$(RUNTIME) CommandLine $$class_names \
>   	>  stdout.log 2>  stderr.log ; \
>   	 cat stdout.log ; \
> diff -r 093896b370d3 netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java
> --- a/netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java	Wed Mar 28 12:08:10 2012 +0200
> +++ b/netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java	Wed Apr 04 16:48:09 2012 +0200
> @@ -107,6 +107,49 @@
>        */
>       public synchronized void load() {
>           cacheOrder.load();
> +
> +        /*
> +         * clean up possibly corrupted entries
> +         */
It is interesting to see how many times is  checkData called during single jar run.. I counted 
10executions.... But fixing this is definitely work for different patch.
> +        if(checkData())
> +            store();
> +
> +    }
> +
> +    /**
> +     * check content of cacheOrder and remove invalid/corrupt entries
> +     */
> +    private boolean checkData () {
> +        boolean modified = false;
> +
> +        for (Entry<Object, Object>  currentEntry : cacheOrder.entrySet()) {
> +            final String key = (String) currentEntry.getKey();
> +            final String path = (String) currentEntry.getValue();
> +
> +            // 1. check key format: "milliseconds,number"
> +            try {
> +                String sa[] = key.split(",");
> +                Long l1 = Long.parseLong(sa[0]);
> +                Long l2 = Long.parseLong(sa[1]);
> +            } catch (Exception ex) {
> +                cacheOrder.remove(key);
> +                modified = true;
> +                continue;
> +            }
> +
> +            // 2. check path format - does the path look correct?
> +            if (path != null) {
> +                if (path.indexOf(cacheDir)<  0) {
> +                    cacheOrder.remove(key);
> +                    modified = true;
> +                }
> +            } else {
> +                cacheOrder.remove(key);
> +                modified = true;
> +            }
> +        }
> +
> +        return modified;
>       }

Really elegant solution this check :)
>
>       /**
> @@ -174,15 +217,11 @@
>           Collections.sort(entries, new Comparator<Entry<String, String>>() {
>               @Override
>               public int compare(Entry<String, String>  e1, Entry<String, String>  e2) {
> -                try {
> -                    Long t1 = Long.parseLong(e1.getKey().split(",")[0]);
> -                    Long t2 = Long.parseLong(e2.getKey().split(",")[0]);
> +                Long t1 = Long.parseLong(e1.getKey().split(",")[0]);
> +                Long t2 = Long.parseLong(e2.getKey().split(",")[0]);
>
> -                    int c = t1.compareTo(t2);
> -                    return c<  0 ? 1 : (c>  0 ? -1 : 0);
> -                } catch (Exception e) {
> -                    throw new LruCacheException(R("Corrupt LRU file entries"));
> -                }
> +                int c = t1.compareTo(t2);
> +                return c<  0 ? 1 : (c>  0 ? -1 : 0);
>               }
>           });
>           return entries;
> diff -r 093896b370d3 netx/net/sourceforge/jnlp/cache/CacheUtil.java
> --- a/netx/net/sourceforge/jnlp/cache/CacheUtil.java	Wed Mar 28 12:08:10 2012 +0200
> +++ b/netx/net/sourceforge/jnlp/cache/CacheUtil.java	Wed Apr 04 16:48:09 2012 +0200
> @@ -308,7 +308,6 @@
>               if (cacheFile == null) { // We did not find a copy of it.
>                   cacheFile = makeNewCacheFile(source, version);
>               }
> -            lruHandler.store();
This scares me - why it have begin to be removed?
>               lruHandler.unlock();
>           }
>           return cacheFile;
> @@ -324,47 +323,19 @@
>           synchronized (lruHandler) {
>               File cacheFile = null;
>               int tries = 0;
> -            List<Entry<String, String>>  entries = null;
> -            do {
> -                try {
> -                    tries++;
> -                    entries = lruHandler.getLRUSortedEntries();
> -                } catch (LruCacheException ex) {
> -                    if (tries == 1) {
> -                        ex.printStackTrace();
> -                        System.out.println(R("CFakeCache"));
> -                        lruHandler.clearLRUSortedEntries();
> -                        lruHandler.store();
> -                        System.out.println(R("CFakedCache"));
> -                    } else if (tries == 2) {
> -                        ex.printStackTrace();
> -                        System.out.println(R("CStillCorupted"));
> -                        boolean clearingresult = CacheUtil.clearCache();
> -                        if (!clearingresult) {
> -                            throw new InternalError(R("CCleaningUnsuccessful"));
> -                        }
> -                        System.out.println(R("CClearedReloading"));
> -                        lruHandler.clearLRUSortedEntries();
> -                        lruHandler.store();
> -                        System.out.println(R("CReloadRestarting"));

Properties texts should be removed to. I have dared to do this. and to reuse little bit modified two 
of them.

> +            List<Entry<String, String>>  entries = lruHandler.getLRUSortedEntries();
>
> -                    } else {
> -                        throw new InternalError(R("CStillBroken"));
> -                    }
> -
> -                }
> -            } while (entries == null);
>               // Start searching from the most recent to least recent.
>               for (Entry<String, String>  e : entries) {
>                   final String key = e.getKey();
>                   final String path = e.getValue();
>
> -                if (path != null) {
> -                    if (pathToURLPath(path).equals(urlPath.getPath())) { // Match found.
> -                        cacheFile = new File(path);
> -                        lruHandler.updateEntry(key);
> -                        break; // Stop searching since we got newest one already.
> -                    }
> +                assert(path!=null);
I'm not friend of assert(...)....
I think this is even not necessary - the self-explaining NullPointerException will be thrown little 
bit later. However I do not insists and do as you wish.
> +
> +                if (pathToURLPath(path).equals(urlPath.getPath())) { // Match found.
> +                    cacheFile = new File(path);
> +                    lruHandler.updateEntry(key);
> +                    break; // Stop searching since we got newest one already.
>                   }
>               }
>               return cacheFile;
> @@ -561,10 +532,13 @@
>        * This will remove all old cache items.
>        */
>       public static void cleanCache() {
> +
>           if (okToClearCache()) {
>               // First we want to figure out which stuff we need to delete.
>               HashSet<String>  keep = new HashSet<String>();
>               HashSet<String>  remove = new HashSet<String>();
> +
> +            // FIXME: lock on recently_used file needed?
>               lruHandler.load();

hmmm .. I do not know:(
>
>               long maxSize = -1; // Default
> @@ -579,57 +553,57 @@
>               for (Entry<String, String>  e : lruHandler.getLRUSortedEntries()) {
>                   // Check if the item is contained in cacheOrder.
>                   final String key = e.getKey();
> -                final String value = e.getValue();
> +                final String path = e.getValue();
>
> -                if (value != null) {
> -                    File file = new File(value);
> -                    PropertiesFile pf = new PropertiesFile(new File(value + ".info"));
> -                    boolean delete = Boolean.parseBoolean(pf.getProperty("delete"));
> +                assert(path!=null);
same assert as above...?...
>
> -                    /*
> -                     * This will get me the root directory specific to this cache item.
> -                     * Example:
> -                     *  cacheDir = /home/user1/.icedtea/cache
> -                     *  file.getPath() = /home/user1/.icedtea/cache/0/http/www.example.com/subdir/a.jar
> -                     *  rStr first becomes: /0/http/www.example.com/subdir/a.jar
> -                     *  then rstr becomes: /home/user1/.icedtea/cache/0
> -                     */
> -                    String rStr = file.getPath().substring(cacheDir.length());
> -                    rStr = cacheDir + rStr.substring(0, rStr.indexOf(File.separatorChar, 1));
> -                    long len = file.length();
> +                File file = new File(path);
> +                PropertiesFile pf = new PropertiesFile(new File(path + ".info"));
> +                boolean delete = Boolean.parseBoolean(pf.getProperty("delete"));
>
> -                    if (keep.contains(file.getPath().substring(rStr.length()))) {
> -                        lruHandler.removeEntry(key);
> -                        continue;
> -                    }
> -
> -                    /*
> -                     * we remove entries from our lru if any of the following condition is met.
> -                     * Conditions:
> -                     *  - delete: file has been marked for deletion.
> -                     *  - !file.isFile(): if someone tampered with the directory, file doesn't exist.
> -                     *  - maxSize>= 0&&  curSize + len>  maxSize: If a limit was set and the new size
> -                     *  on disk would exceed the maximum size.
> -                     */
> -                    if (delete || !file.isFile() || (maxSize>= 0&&  curSize + len>  maxSize)) {
> -                        lruHandler.removeEntry(key);
> -                        remove.add(rStr);
> -                    } else {
> -                        curSize += len;
> -                        keep.add(file.getPath().substring(rStr.length()));
> +                /*
> +                 * This will get me the root directory specific to this cache item.
> +                 * Example:
> +                 *  cacheDir = /home/user1/.icedtea/cache
> +                 *  file.getPath() = /home/user1/.icedtea/cache/0/http/www.example.com/subdir/a.jar
> +                 *  rStr first becomes: /0/http/www.example.com/subdir/a.jar
> +                 *  then rstr becomes: /home/user1/.icedtea/cache/0
> +                 */
> +                String rStr = file.getPath().substring(cacheDir.length());
> +                rStr = cacheDir + rStr.substring(0, rStr.indexOf(File.separatorChar, 1));
> +                long len = file.length();
>
> -                        for (File f : file.getParentFile().listFiles()) {
> -                            if (!(f.equals(file) || f.equals(pf.getStoreFile()))){
> -                                try {
> -                                    FileUtils.recursiveDelete(f, f);
> -                                } catch (IOException e1) {
> -                                    e1.printStackTrace();
> -                                }
> -                            }
> +                if (keep.contains(file.getPath().substring(rStr.length()))) {
> +                    lruHandler.removeEntry(key);
> +                    continue;
> +                }
> +
> +                /*
> +                 * we remove entries from our lru if any of the following condition is met.
> +                 * Conditions:
> +                 *  - delete: file has been marked for deletion.
> +                 *  - !file.isFile(): if someone tampered with the directory, file doesn't exist.
> +                 *  - maxSize>= 0&&  curSize + len>  maxSize: If a limit was set and the new size
> +                 *  on disk would exceed the maximum size.
> +                 */
> +                if (delete || !file.isFile() || (maxSize>= 0&&  curSize + len>  maxSize)) {
> +                    lruHandler.removeEntry(key);
> +                    remove.add(rStr);
> +                    continue;
> +                }
> +
> +                curSize += len;
> +                keep.add(file.getPath().substring(rStr.length()));
> +
> +                for (File f : file.getParentFile().listFiles()) {
> +                    if (!(f.equals(file) || f.equals(pf.getStoreFile()))){
> +                        try {
> +                            FileUtils.recursiveDelete(f, f);
> +                        } catch (IOException e1) {
> +                            e1.printStackTrace();
>                           }
>                       }
> -                } else {
> -                    lruHandler.removeEntry(key);
> +
>                   }

I must admit that I did not got fully the meaning of this change. But it is working pretty fine and 
looks ok :)
>               }
>               lruHandler.store();
> diff -r 093896b370d3 netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java
> --- a/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java	Wed Mar 28 12:08:10 2012 +0200
> +++ b/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java	Wed Apr 04 16:48:09 2012 +0200
> @@ -713,6 +713,7 @@
>           Runtime.getRuntime().addShutdownHook(new Thread() {
>               public void run() {
>                   markNetxStopped();
> +                // no lock on recently_used file needed?
I'm not sure again as above :(
>                   CacheUtil.cleanCache();
>               }
>           });
>

I hope my small changes will not insult you, but while I was playing with your changeset they looks 
to me like essential ones so I put them in instead of describing.

If you will agree with printing of lrucacheexception stacktrace then this is nearly done.
If you will insists on no stacktreace printing or (what I prefer) on printing it out just in debug 
mode, then the tests will need little fixing. (for case with no stacktraces it will need to change 
testing conditions, and for stacktace printed in debugmode it will need to run javaws in verbose mode)

Best regards and thanx for patch.

J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: thomasImprovedCacheFix.diff
Type: text/x-patch
Size: 21141 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120405/b4cf79ac/thomasImprovedCacheFix.diff 

From thomas at m3y3r.de  Thu Apr  5 06:30:51 2012
From: thomas at m3y3r.de (Thomas Meyer)
Date: Thu, 05 Apr 2012 15:30:51 +0200
Subject: [RFC] Fix IndexOutOfBoundException because of corrupted entry
	in recently_used file
In-Reply-To: <4F7D9742.4010608@redhat.com>
References: <1332938501.1397.15.camel@localhost.localdomain>
	<4F79A620.2090702@redhat.com>
	<1333447622.5010.11.camel@localhost.localdomain>
	<4F7AE134.7080500@redhat.com>
	<1333458882.5010.14.camel@localhost.localdomain>
	<4F7B0E34.7010209@redhat.com>
	<1333551460.6613.13.camel@localhost.localdomain>
	<4F7D9742.4010608@redhat.com>
Message-ID: <1333632651.6613.43.camel@localhost.localdomain>

Am Donnerstag, den 05.04.2012, 14:59 +0200 schrieb Jiri Vanek:
> On 04/04/2012 04:57 PM, Thomas Meyer wrote:
> > Am Dienstag, den 03.04.2012, 16:50 +0200 schrieb Jiri Vanek:
> >> >  Thanx for test! Logic itself is good, but there are two mistakes which causes the test to be not-working.
> >> >  See notes inline for them.
> > Hi,
> >
> > I hacked a bit on this today. please have a look at the attached patch.
> >
> > I moved all the format checks in the CacheLRUWrapper.load() method. that
> > is the place were I think they actually belong.
> >
> > I guess these changes will break the CacheReproducerTest as no more
> > LRUExceptions are thrown.
> I would like to notice outside world that cache was corrupted. (LruCacheException) 
> ex.printStacktrace  can be as good as anything else (and is backward compatible with existing approach.
> 
> However to print stacktrace just in debug mode will be probably better idea.
> Plus information text I have dared to add.

fine for me.

> >
> > what do you think about this approach? does this make sense for you?
> 
> Yap! I till it excellent. It is also handling multiple launches upon broken cache better then my 
> original fix did.
>   Although there was an bug in removing item from cache with running iteration  (which was causing 
> ConcurrentModificationException)

oops. good catch. thanks.

> 
> I have dared to fix this and LruCacheException printing and to include working tests to your 
> original patch. This "improved" one is attached.

looks good to me.

> 
> However still several questions to your original one in-line:

see my answers below.

> >
> >
> > check-cache-data.patch
> >
> >
> > diff -r 093896b370d3 Makefile.am
> > --- a/Makefile.am	Wed Mar 28 12:08:10 2012 +0200
> > +++ b/Makefile.am	Wed Apr 04 16:48:09 2012 +0200
> > @@ -565,7 +565,7 @@
> >   	cd $(JNLP_TESTS_ENGINE_DIR) ; \
> >   	class_names=`cat $(REPRODUCERS_CLASS_NAMES)` ; \
> >   	CLASSPATH=$(NETX_DIR)/lib/classes.jar:$(JUNIT_JAR):$(JUNIT_RUNNER_JAR):. \
> > -	  $(BOOT_DIR)/bin/java -Dtest.server.dir=$(JNLP_TESTS_SERVER_DEPLOYDIR) -Djavaws.build.bin=$(DESTDIR)$(bindir)/javaws \
> > +	  $(BOOT_DIR)/bin/java -Dtest.server.dir=$(JNLP_TESTS_SERVER_DEPLOYDIR) -Djavaws.build.bin=$(DESTDIR)$(bindir)/$(javaws) \
> >   	 -Xbootclasspath:$(RUNTIME) CommandLine $$class_names \
> >   	>  stdout.log 2>  stderr.log ; \
> >   	 cat stdout.log ; \
> > diff -r 093896b370d3 netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java
> > --- a/netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java	Wed Mar 28 12:08:10 2012 +0200
> > +++ b/netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java	Wed Apr 04 16:48:09 2012 +0200
> > @@ -107,6 +107,49 @@
> >        */
> >       public synchronized void load() {
> >           cacheOrder.load();
> > +
> > +        /*
> > +         * clean up possibly corrupted entries
> > +         */
> It is interesting to see how many times is  checkData called during single jar run.. I counted 
> 10executions.... But fixing this is definitely work for different patch.

yeah, I also noticed this. maybe this can be reduced a bit. see below
comment for getCacheFile(). but as the recently_used file could be
corrupted by another jvm process (etc.), we need to check this on every
load.

> > +        if(checkData())
> > +            store();
> > +
> > +    }
> > +
> > +    /**
> > +     * check content of cacheOrder and remove invalid/corrupt entries
> > +     */
> > +    private boolean checkData () {
> > +        boolean modified = false;
> > +
> > +        for (Entry<Object, Object>  currentEntry : cacheOrder.entrySet()) {
> > +            final String key = (String) currentEntry.getKey();
> > +            final String path = (String) currentEntry.getValue();
> > +
> > +            // 1. check key format: "milliseconds,number"
> > +            try {
> > +                String sa[] = key.split(",");
> > +                Long l1 = Long.parseLong(sa[0]);
> > +                Long l2 = Long.parseLong(sa[1]);
> > +            } catch (Exception ex) {
> > +                cacheOrder.remove(key);
> > +                modified = true;
> > +                continue;
> > +            }
> > +
> > +            // 2. check path format - does the path look correct?
> > +            if (path != null) {
> > +                if (path.indexOf(cacheDir)<  0) {
> > +                    cacheOrder.remove(key);
> > +                    modified = true;
> > +                }
> > +            } else {
> > +                cacheOrder.remove(key);
> > +                modified = true;
> > +            }
> > +        }
> > +
> > +        return modified;
> >       }
> 
> Really elegant solution this check :)
> >
> >       /**
> > @@ -174,15 +217,11 @@
> >           Collections.sort(entries, new Comparator<Entry<String, String>>() {
> >               @Override
> >               public int compare(Entry<String, String>  e1, Entry<String, String>  e2) {
> > -                try {
> > -                    Long t1 = Long.parseLong(e1.getKey().split(",")[0]);
> > -                    Long t2 = Long.parseLong(e2.getKey().split(",")[0]);
> > +                Long t1 = Long.parseLong(e1.getKey().split(",")[0]);
> > +                Long t2 = Long.parseLong(e2.getKey().split(",")[0]);
> >
> > -                    int c = t1.compareTo(t2);
> > -                    return c<  0 ? 1 : (c>  0 ? -1 : 0);
> > -                } catch (Exception e) {
> > -                    throw new LruCacheException(R("Corrupt LRU file entries"));
> > -                }
> > +                int c = t1.compareTo(t2);
> > +                return c<  0 ? 1 : (c>  0 ? -1 : 0);
> >               }
> >           });
> >           return entries;
> > diff -r 093896b370d3 netx/net/sourceforge/jnlp/cache/CacheUtil.java
> > --- a/netx/net/sourceforge/jnlp/cache/CacheUtil.java	Wed Mar 28 12:08:10 2012 +0200
> > +++ b/netx/net/sourceforge/jnlp/cache/CacheUtil.java	Wed Apr 04 16:48:09 2012 +0200
> > @@ -308,7 +308,6 @@
> >               if (cacheFile == null) { // We did not find a copy of it.
> >                   cacheFile = makeNewCacheFile(source, version);
> >               }
> > -            lruHandler.store();
> This scares me - why it have begin to be removed?

in getCacheFile() method this happens:

1.) call load() -> this must happen, because of concurrent update by
other jvm processes.
2.) checks if entry exists
2a.) when yes -> return the cacheFile entry
2b.) when no  -> call makeNewCacheFile() -> will call load() and
store().
3.) call store() again -> so this one can be omitted as the store will
happen in makeNewCacheFile(), in already existing entry case, no store
is needed.
4.) return cacheFile entry

so here a superfluous store() is removed, as the store() will happen in
makeNewCacheFile() anyway. we may can get rid of the superfluous load()
in makeNewCacheFile() in this case, too?

> >               lruHandler.unlock();
> >           }
> >           return cacheFile;
> > @@ -324,47 +323,19 @@
> >           synchronized (lruHandler) {
> >               File cacheFile = null;
> >               int tries = 0;
> > -            List<Entry<String, String>>  entries = null;
> > -            do {
> > -                try {
> > -                    tries++;
> > -                    entries = lruHandler.getLRUSortedEntries();
> > -                } catch (LruCacheException ex) {
> > -                    if (tries == 1) {
> > -                        ex.printStackTrace();
> > -                        System.out.println(R("CFakeCache"));
> > -                        lruHandler.clearLRUSortedEntries();
> > -                        lruHandler.store();
> > -                        System.out.println(R("CFakedCache"));
> > -                    } else if (tries == 2) {
> > -                        ex.printStackTrace();
> > -                        System.out.println(R("CStillCorupted"));
> > -                        boolean clearingresult = CacheUtil.clearCache();
> > -                        if (!clearingresult) {
> > -                            throw new InternalError(R("CCleaningUnsuccessful"));
> > -                        }
> > -                        System.out.println(R("CClearedReloading"));
> > -                        lruHandler.clearLRUSortedEntries();
> > -                        lruHandler.store();
> > -                        System.out.println(R("CReloadRestarting"));
> 
> Properties texts should be removed to. I have dared to do this. and to reuse little bit modified two 
> of them.

correct, I missed that. thanks

> 
> > +            List<Entry<String, String>>  entries = lruHandler.getLRUSortedEntries();
> >
> > -                    } else {
> > -                        throw new InternalError(R("CStillBroken"));
> > -                    }
> > -
> > -                }
> > -            } while (entries == null);
> >               // Start searching from the most recent to least recent.
> >               for (Entry<String, String>  e : entries) {
> >                   final String key = e.getKey();
> >                   final String path = e.getValue();
> >
> > -                if (path != null) {
> > -                    if (pathToURLPath(path).equals(urlPath.getPath())) { // Match found.
> > -                        cacheFile = new File(path);
> > -                        lruHandler.updateEntry(key);
> > -                        break; // Stop searching since we got newest one already.
> > -                    }
> > +                assert(path!=null);
> I'm not friend of assert(...)....

I don't care about asserts(). They don't hurt as they are not active
anyway.

> I think this is even not necessary - the self-explaining NullPointerException will be thrown little 
> bit later. However I do not insists and do as you wish.
Feel free to remove the asserts. I automatically write them in the code,
because they don't really hurt.

> > +
> > +                if (pathToURLPath(path).equals(urlPath.getPath())) { // Match found.
> > +                    cacheFile = new File(path);
> > +                    lruHandler.updateEntry(key);
> > +                    break; // Stop searching since we got newest one already.
> >                   }
> >               }
> >               return cacheFile;
> > @@ -561,10 +532,13 @@
> >        * This will remove all old cache items.
> >        */
> >       public static void cleanCache() {
> > +
> >           if (okToClearCache()) {
> >               // First we want to figure out which stuff we need to delete.
> >               HashSet<String>  keep = new HashSet<String>();
> >               HashSet<String>  remove = new HashSet<String>();
> > +
> > +            // FIXME: lock on recently_used file needed?
> >               lruHandler.load();
> 
> hmmm .. I do not know:(

I guess it is not okay, as another javaws process could update the
recently_used file concurrently, maybe nobody did hit this situation. I
think the cleanChache() should be protected by a FileLock...

> >
> >               long maxSize = -1; // Default
> > @@ -579,57 +553,57 @@
> >               for (Entry<String, String>  e : lruHandler.getLRUSortedEntries()) {
> >                   // Check if the item is contained in cacheOrder.
> >                   final String key = e.getKey();
> > -                final String value = e.getValue();
> > +                final String path = e.getValue();
> >
> > -                if (value != null) {
> > -                    File file = new File(value);
> > -                    PropertiesFile pf = new PropertiesFile(new File(value + ".info"));
> > -                    boolean delete = Boolean.parseBoolean(pf.getProperty("delete"));
> > +                assert(path!=null);
> same assert as above...?...
yes. path must be not null here.

> >
> > -                    /*
> > -                     * This will get me the root directory specific to this cache item.
> > -                     * Example:
> > -                     *  cacheDir = /home/user1/.icedtea/cache
> > -                     *  file.getPath() = /home/user1/.icedtea/cache/0/http/www.example.com/subdir/a.jar
> > -                     *  rStr first becomes: /0/http/www.example.com/subdir/a.jar
> > -                     *  then rstr becomes: /home/user1/.icedtea/cache/0
> > -                     */
> > -                    String rStr = file.getPath().substring(cacheDir.length());
> > -                    rStr = cacheDir + rStr.substring(0, rStr.indexOf(File.separatorChar, 1));
> > -                    long len = file.length();
> > +                File file = new File(path);
> > +                PropertiesFile pf = new PropertiesFile(new File(path + ".info"));
> > +                boolean delete = Boolean.parseBoolean(pf.getProperty("delete"));
> >
> > -                    if (keep.contains(file.getPath().substring(rStr.length()))) {
> > -                        lruHandler.removeEntry(key);
> > -                        continue;
> > -                    }
> > -
> > -                    /*
> > -                     * we remove entries from our lru if any of the following condition is met.
> > -                     * Conditions:
> > -                     *  - delete: file has been marked for deletion.
> > -                     *  - !file.isFile(): if someone tampered with the directory, file doesn't exist.
> > -                     *  - maxSize>= 0&&  curSize + len>  maxSize: If a limit was set and the new size
> > -                     *  on disk would exceed the maximum size.
> > -                     */
> > -                    if (delete || !file.isFile() || (maxSize>= 0&&  curSize + len>  maxSize)) {
> > -                        lruHandler.removeEntry(key);
> > -                        remove.add(rStr);
> > -                    } else {
> > -                        curSize += len;
> > -                        keep.add(file.getPath().substring(rStr.length()));
> > +                /*
> > +                 * This will get me the root directory specific to this cache item.
> > +                 * Example:
> > +                 *  cacheDir = /home/user1/.icedtea/cache
> > +                 *  file.getPath() = /home/user1/.icedtea/cache/0/http/www.example.com/subdir/a.jar
> > +                 *  rStr first becomes: /0/http/www.example.com/subdir/a.jar
> > +                 *  then rstr becomes: /home/user1/.icedtea/cache/0
> > +                 */
> > +                String rStr = file.getPath().substring(cacheDir.length());
> > +                rStr = cacheDir + rStr.substring(0, rStr.indexOf(File.separatorChar, 1));
> > +                long len = file.length();
> >
> > -                        for (File f : file.getParentFile().listFiles()) {
> > -                            if (!(f.equals(file) || f.equals(pf.getStoreFile()))){
> > -                                try {
> > -                                    FileUtils.recursiveDelete(f, f);
> > -                                } catch (IOException e1) {
> > -                                    e1.printStackTrace();
> > -                                }
> > -                            }
> > +                if (keep.contains(file.getPath().substring(rStr.length()))) {
> > +                    lruHandler.removeEntry(key);
> > +                    continue;
> > +                }
> > +
> > +                /*
> > +                 * we remove entries from our lru if any of the following condition is met.
> > +                 * Conditions:
> > +                 *  - delete: file has been marked for deletion.
> > +                 *  - !file.isFile(): if someone tampered with the directory, file doesn't exist.
> > +                 *  - maxSize>= 0&&  curSize + len>  maxSize: If a limit was set and the new size
> > +                 *  on disk would exceed the maximum size.
> > +                 */
> > +                if (delete || !file.isFile() || (maxSize>= 0&&  curSize + len>  maxSize)) {
> > +                    lruHandler.removeEntry(key);
> > +                    remove.add(rStr);
> > +                    continue;
> > +                }
> > +
> > +                curSize += len;
> > +                keep.add(file.getPath().substring(rStr.length()));
> > +
> > +                for (File f : file.getParentFile().listFiles()) {
> > +                    if (!(f.equals(file) || f.equals(pf.getStoreFile()))){
> > +                        try {
> > +                            FileUtils.recursiveDelete(f, f);
> > +                        } catch (IOException e1) {
> > +                            e1.printStackTrace();
> >                           }
> >                       }
> > -                } else {
> > -                    lruHandler.removeEntry(key);
> > +
> >                   }
> 
> I must admit that I did not got fully the meaning of this change. But it is working pretty fine and 
> looks ok :)

the idea is to remove the check for "if(path != null)", as we did
already make sure in load()->checkData() that the path is not null.
that's all.

> >               }
> >               lruHandler.store();
> > diff -r 093896b370d3 netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java
> > --- a/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java	Wed Mar 28 12:08:10 2012 +0200
> > +++ b/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java	Wed Apr 04 16:48:09 2012 +0200
> > @@ -713,6 +713,7 @@
> >           Runtime.getRuntime().addShutdownHook(new Thread() {
> >               public void run() {
> >                   markNetxStopped();
> > +                // no lock on recently_used file needed?
> I'm not sure again as above :(
> >                   CacheUtil.cleanCache();
> >               }
> >           });
> >
> 
> I hope my small changes will not insult you, but while I was playing with your changeset they looks 
> to me like essential ones so I put them in instead of describing.

I couldn't see any insults in this mail :-) Just good improvements to me
patch.

> 
> If you will agree with printing of lrucacheexception stacktrace then this is nearly done.
Im' fine with the printing.

> If you will insists on no stacktreace printing or (what I prefer) on printing it out just in debug 
> mode, then the tests will need little fixing. (for case with no stacktraces it will need to change 
> testing conditions, and for stacktace printed in debugmode it will need to run javaws in verbose mode)
> 
> Best regards and thanx for patch.

my pleasure.

with kind regards
thomas




From ddadacha at icedtea.classpath.org  Thu Apr  5 07:58:24 2012
From: ddadacha at icedtea.classpath.org (ddadacha at icedtea.classpath.org)
Date: Thu, 05 Apr 2012 14:58:24 +0000
Subject: /hg/icedtea-web: Rename JarSigner to JarCertVerifier.
Message-ID: <hg.cde6d59a2901.1333637904.8643924302249223276@icedtea.classpath.org>

changeset cde6d59a2901 in /hg/icedtea-web
details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=cde6d59a2901
author: Danesh Dadachanji <ddadacha at redhat.com>
date: Thu Apr 05 10:57:16 2012 -0400

	Rename JarSigner to JarCertVerifier.


diffstat:

 ChangeLog                                               |   20 +
 netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java  |   52 +-
 netx/net/sourceforge/jnlp/security/CertWarningPane.java |    8 +-
 netx/net/sourceforge/jnlp/security/CertsInfoPane.java   |    2 +-
 netx/net/sourceforge/jnlp/security/MoreInfoPane.java    |    2 +-
 netx/net/sourceforge/jnlp/security/SecurityDialog.java  |   22 +-
 netx/net/sourceforge/jnlp/security/SecurityDialogs.java |    6 +-
 netx/net/sourceforge/jnlp/tools/JarCertVerifier.java    |  555 ++++++++++++++++
 netx/net/sourceforge/jnlp/tools/JarSigner.java          |  555 ----------------
 netx/net/sourceforge/jnlp/tools/KeyStoreUtil.java       |    2 +-
 10 files changed, 622 insertions(+), 602 deletions(-)

diffs (truncated from 1471 to 500 lines):

diff -r 16a8b7bfee7d -r cde6d59a2901 ChangeLog
--- a/ChangeLog	Thu Apr 05 12:52:22 2012 +0200
+++ b/ChangeLog	Thu Apr 05 10:57:16 2012 -0400
@@ -1,3 +1,23 @@
+2012-04-04  Danesh Dadachanji  <ddadacha at redhat.com>
+	Change the name of JarSigner to JarCertVerifier to make it more
+	relevant to the purpose of the file.
+	* netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java
+	* netx/net/sourceforge/jnlp/tools/KeyStoreUtil.java:
+	Replace all instances, paramaters and references of JarSigner
+	by JarCertVerifier.
+	* netx/net/sourceforge/jnlp/security/CertWarningPane.java
+	* netx/net/sourceforge/jnlp/security/CertsInfoPane.java
+	* netx/net/sourceforge/jnlp/security/MoreInfoPane.java
+	* netx/net/sourceforge/jnlp/security/SecurityDialogs.java:
+	Replaced all paramaters, references and variable names of JarSigner
+	to CertVerifier to match the variable object type.
+	* netx/net/sourceforge/jnlp/security/SecurityDialog.java (getJarSigner):
+	Renamed to getCertVerifier as it returns the certVerfier instance.
+	* netx/net/sourceforge/jnlp/tools/JarSigner.java:
+	Renamed to JarCertVerifier.
+	* netx/net/sourceforge/jnlp/tools/JarCertVerifier.java:
+	The rename of JarSigner.
+
 2012-04-05  Jiri Vanek <jvanek at redhat.com>
 
 	Fixing issue when process was not launched at all and when was killed but
diff -r 16a8b7bfee7d -r cde6d59a2901 netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java
--- a/netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java	Thu Apr 05 12:52:22 2012 +0200
+++ b/netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java	Thu Apr 05 10:57:16 2012 -0400
@@ -72,7 +72,7 @@
 import net.sourceforge.jnlp.cache.UpdatePolicy;
 import net.sourceforge.jnlp.security.SecurityDialogs;
 import net.sourceforge.jnlp.security.SecurityDialogs.AccessType;
-import net.sourceforge.jnlp.tools.JarSigner;
+import net.sourceforge.jnlp.tools.JarCertVerifier;
 import net.sourceforge.jnlp.util.FileUtils;
 import sun.misc.JarIndex;
 
@@ -150,8 +150,8 @@
     /** all of the jar files that were not verified */
     private ArrayList<String> unverifiedJars = null;
 
-    /** the jarsigner tool to verify our jars */
-    private JarSigner js = null;
+    /** the jar cert verifier tool to verify our jars */
+    private JarCertVerifier jcv = null;
 
     private boolean signing = false;
 
@@ -469,13 +469,13 @@
 
         if (JNLPRuntime.isVerifying()) {
 
-            JarSigner js;
+            JarCertVerifier jcv;
             waitForJars(initialJars); //download the jars first.
 
             try {
-                js = verifyJars(initialJars);
+                jcv = verifyJars(initialJars);
             } catch (Exception e) {
-                //we caught an Exception from the JarSigner class.
+                //we caught an Exception from the JarCertVerifier class.
                 //Note: one of these exceptions could be from not being able
                 //to read the cacerts or trusted.certs files.
                 e.printStackTrace();
@@ -484,10 +484,10 @@
             }
 
             //Case when at least one jar has some signing
-            if (js.anyJarsSigned() && js.isFullySignedByASingleCert()) {
+            if (jcv.anyJarsSigned() && jcv.isFullySignedByASingleCert()) {
                 signing = true;
 
-                if (!js.allJarsSigned() &&
+                if (!jcv.allJarsSigned() &&
                                     !SecurityDialogs.showNotAllSignedWarningDialog(file))
                     throw new LaunchException(file, null, R("LSFatal"), R("LCClient"), R("LSignedAppJarUsingUnsignedJar"), R("LSignedAppJarUsingUnsignedJarInfo"));
 
@@ -515,8 +515,8 @@
                     file.setSignedJNLPAsMissing();
                 
                 //user does not trust this publisher
-                if (!js.getAlreadyTrustPublisher()) {
-                    checkTrustWithUser(js);
+                if (!jcv.getAlreadyTrustPublisher()) {
+                    checkTrustWithUser(jcv);
                 } else {
                     /**
                      * If the user trusts this publisher (i.e. the publisher's certificate
@@ -700,7 +700,7 @@
     private void verifySignedJNLP(JARDesc jarDesc, JarFile jarFile)
             throws LaunchException {
 
-        JarSigner signer = new JarSigner();
+        JarCertVerifier signer = new JarCertVerifier();
         List<JARDesc> desc = new ArrayList<JARDesc>();
         desc.add(jarDesc);
 
@@ -797,7 +797,7 @@
             /*
              * After this exception is caught, it is escaped. If an exception is
              * thrown while handling the jar file, (mainly for
-             * JarSigner.verifyJars) it assumes the jar file is unsigned and
+             * JarCertVerifier.verifyJars) it assumes the jar file is unsigned and
              * skip the check for a signed JNLP file
              */
             
@@ -828,24 +828,24 @@
             }
     }
     
-    private void checkTrustWithUser(JarSigner js) throws LaunchException {
+    private void checkTrustWithUser(JarCertVerifier jcv) throws LaunchException {
         if (JNLPRuntime.isTrustAll()){
             return;
         }
-        if (!js.getRootInCacerts()) { //root cert is not in cacerts
+        if (!jcv.getRootInCacerts()) { //root cert is not in cacerts
             boolean b = SecurityDialogs.showCertWarningDialog(
-                    AccessType.UNVERIFIED, file, js);
+                    AccessType.UNVERIFIED, file, jcv);
             if (!b)
                 throw new LaunchException(null, null, R("LSFatal"),
                         R("LCLaunching"), R("LNotVerified"), "");
-        } else if (js.getRootInCacerts()) { //root cert is in cacerts
+        } else if (jcv.getRootInCacerts()) { //root cert is in cacerts
             boolean b = false;
-            if (js.noSigningIssues())
+            if (jcv.noSigningIssues())
                 b = SecurityDialogs.showCertWarningDialog(
-                        AccessType.VERIFIED, file, js);
-            else if (!js.noSigningIssues())
+                        AccessType.VERIFIED, file, jcv);
+            else if (!jcv.noSigningIssues())
                 b = SecurityDialogs.showCertWarningDialog(
-                        AccessType.SIGNING_ERROR, file, js);
+                        AccessType.SIGNING_ERROR, file, jcv);
             if (!b)
                 throw new LaunchException(null, null, R("LSFatal"),
                         R("LCLaunching"), R("LCancelOnUserRequest"), "");
@@ -1031,7 +1031,7 @@
                                         continue;
                                     }
 
-                                    JarSigner signer = new JarSigner();
+                                    JarCertVerifier signer = new JarCertVerifier();
                                     List<JARDesc> jars = new ArrayList<JARDesc>();
                                     JARDesc jarDesc = new JARDesc(new File(extractedJarLocation).toURL(), null, null, false, false, false, false);
                                     jars.add(jarDesc);
@@ -1280,11 +1280,11 @@
          *
          * @param jars the jars to be verified.
          */
-    private JarSigner verifyJars(List<JARDesc> jars) throws Exception {
+    private JarCertVerifier verifyJars(List<JARDesc> jars) throws Exception {
 
-        js = new JarSigner();
-        js.verifyJars(jars, tracker);
-        return js;
+        jcv = new JarCertVerifier();
+        jcv.verifyJars(jars, tracker);
+        return jcv;
     }
 
     /**
@@ -1442,7 +1442,7 @@
 
             // Verify if needed
 
-            final JarSigner signer = new JarSigner();
+            final JarCertVerifier signer = new JarCertVerifier();
             final List<JARDesc> jars = new ArrayList<JARDesc>();
             jars.add(desc);
 
diff -r 16a8b7bfee7d -r cde6d59a2901 netx/net/sourceforge/jnlp/security/CertWarningPane.java
--- a/netx/net/sourceforge/jnlp/security/CertWarningPane.java	Thu Apr 05 12:52:22 2012 +0200
+++ b/netx/net/sourceforge/jnlp/security/CertWarningPane.java	Thu Apr 05 10:57:16 2012 -0400
@@ -96,7 +96,7 @@
     private void addComponents() {
         AccessType type = parent.getAccessType();
         JNLPFile file = parent.getFile();
-        Certificate c = parent.getJarSigner().getPublisher();
+        Certificate c = parent.getCertVerifier().getPublisher();
 
         String name = "";
         String publisher = "";
@@ -222,7 +222,7 @@
         JButton moreInfo = new JButton(R("ButMoreInformation"));
         moreInfo.addActionListener(new MoreInfoButtonListener());
 
-        if (parent.getJarSigner().getRootInCacerts())
+        if (parent.getCertVerifier().getRootInCacerts())
             bottomLabel = new JLabel(htmlWrap(R("STrustedSource")));
         else
             bottomLabel = new JLabel(htmlWrap(R("SUntrustedSource")));
@@ -239,7 +239,7 @@
 
     private class MoreInfoButtonListener implements ActionListener {
         public void actionPerformed(ActionEvent e) {
-            SecurityDialog.showMoreInfoDialog(parent.getJarSigner(),
+            SecurityDialog.showMoreInfoDialog(parent.getCertVerifier(),
                                 parent);
         }
     }
@@ -252,7 +252,7 @@
             if (alwaysTrust != null && alwaysTrust.isSelected()) {
                 try {
                     KeyStore ks = KeyStores.getKeyStore(Level.USER, Type.CERTS);
-                    X509Certificate c = (X509Certificate) parent.getJarSigner().getPublisher();
+                    X509Certificate c = (X509Certificate) parent.getCertVerifier().getPublisher();
                     CertificateUtils.addToKeyStore(c, ks);
                     File keyStoreFile = new File(KeyStores.getKeyStoreLocation(Level.USER, Type.CERTS));
                     if (!keyStoreFile.isFile()) {
diff -r 16a8b7bfee7d -r cde6d59a2901 netx/net/sourceforge/jnlp/security/CertsInfoPane.java
--- a/netx/net/sourceforge/jnlp/security/CertsInfoPane.java	Thu Apr 05 12:52:22 2012 +0200
+++ b/netx/net/sourceforge/jnlp/security/CertsInfoPane.java	Thu Apr 05 10:57:16 2012 -0400
@@ -84,7 +84,7 @@
      * Builds the JTree out of CertPaths.
      */
     void buildTree() {
-        certPath = parent.getJarSigner().getCertPath();
+        certPath = parent.getCertVerifier().getCertPath();
         X509Certificate firstCert =
                         ((X509Certificate) certPath.getCertificates().get(0));
         String subjectString =
diff -r 16a8b7bfee7d -r cde6d59a2901 netx/net/sourceforge/jnlp/security/MoreInfoPane.java
--- a/netx/net/sourceforge/jnlp/security/MoreInfoPane.java	Thu Apr 05 12:52:22 2012 +0200
+++ b/netx/net/sourceforge/jnlp/security/MoreInfoPane.java	Thu Apr 05 10:57:16 2012 -0400
@@ -118,7 +118,7 @@
 
     private class CertInfoButtonListener implements ActionListener {
         public void actionPerformed(ActionEvent e) {
-            SecurityDialog.showCertInfoDialog(parent.getJarSigner(),
+            SecurityDialog.showCertInfoDialog(parent.getCertVerifier(),
                                 parent);
         }
     }
diff -r 16a8b7bfee7d -r cde6d59a2901 netx/net/sourceforge/jnlp/security/SecurityDialog.java
--- a/netx/net/sourceforge/jnlp/security/SecurityDialog.java	Thu Apr 05 12:52:22 2012 +0200
+++ b/netx/net/sourceforge/jnlp/security/SecurityDialog.java	Thu Apr 05 10:57:16 2012 -0400
@@ -96,12 +96,12 @@
     private boolean requiresSignedJNLPWarning;
 
     SecurityDialog(DialogType dialogType, AccessType accessType,
-                JNLPFile file, CertVerifier jarSigner, X509Certificate cert, Object[] extras) {
+                JNLPFile file, CertVerifier JarCertVerifier, X509Certificate cert, Object[] extras) {
         super();
         this.dialogType = dialogType;
         this.accessType = accessType;
         this.file = file;
-        this.certVerifier = jarSigner;
+        this.certVerifier = JarCertVerifier;
         this.cert = cert;
         this.extras = extras;
         initialized = true;
@@ -124,8 +124,8 @@
      * Create a SecurityDialog to display a certificate-related warning
      */
     SecurityDialog(DialogType dialogType, AccessType accessType,
-                        JNLPFile file, CertVerifier jarSigner) {
-        this(dialogType, accessType, file, jarSigner, null, null);
+                        JNLPFile file, CertVerifier certVerifier) {
+        this(dialogType, accessType, file, certVerifier, null, null);
     }
 
     /**
@@ -164,16 +164,16 @@
     /**
      * Shows more information regarding jar code signing
      *
-     * @param jarSigner the JarSigner used to verify this application
+     * @param certVerifier the JarCertVerifier used to verify this application
      * @param parent the parent option pane
      */
     public static void showMoreInfoDialog(
-                CertVerifier jarSigner, SecurityDialog parent) {
+                CertVerifier certVerifier, SecurityDialog parent) {
 
         JNLPFile file= parent.getFile();
         SecurityDialog dialog =
                         new SecurityDialog(DialogType.MORE_INFO, null, file,
-                                jarSigner);
+                                certVerifier);
         dialog.setModalityType(ModalityType.APPLICATION_MODAL);
         dialog.setVisible(true);
         dialog.dispose();
@@ -182,13 +182,13 @@
     /**
      * Displays CertPath information in a readable table format.
      *
-     * @param jarSigner the JarSigner used to verify this application
+     * @param certVerifier the JarCertVerifier used to verify this application
      * @param parent the parent option pane
      */
-    public static void showCertInfoDialog(CertVerifier jarSigner,
+    public static void showCertInfoDialog(CertVerifier certVerifier,
                 SecurityDialog parent) {
         SecurityDialog dialog = new SecurityDialog(DialogType.CERT_INFO,
-                        null, null, jarSigner);
+                        null, null, certVerifier);
         dialog.setLocationRelativeTo(parent);
         dialog.setModalityType(ModalityType.APPLICATION_MODAL);
         dialog.setVisible(true);
@@ -276,7 +276,7 @@
         return file;
     }
 
-    public CertVerifier getJarSigner() {
+    public CertVerifier getCertVerifier() {
         return certVerifier;
     }
 
diff -r 16a8b7bfee7d -r cde6d59a2901 netx/net/sourceforge/jnlp/security/SecurityDialogs.java
--- a/netx/net/sourceforge/jnlp/security/SecurityDialogs.java	Thu Apr 05 12:52:22 2012 +0200
+++ b/netx/net/sourceforge/jnlp/security/SecurityDialogs.java	Thu Apr 05 10:57:16 2012 -0400
@@ -180,12 +180,12 @@
      *
      * @param accessType the type of warning dialog to show
      * @param file the JNLPFile associated with this warning
-     * @param jarSigner the JarSigner used to verify this application
+     * @param certVerifier the JarCertVerifier used to verify this application
      *
      * @return true if the user accepted the certificate
      */
     public static boolean showCertWarningDialog(AccessType accessType,
-            JNLPFile file, CertVerifier jarSigner) {
+            JNLPFile file, CertVerifier certVerifier) {
 
         if (!shouldPromptUser()) {
             return false;
@@ -195,7 +195,7 @@
         message.dialogType = DialogType.CERT_WARNING;
         message.accessType = accessType;
         message.file = file;
-        message.certVerifier = jarSigner;
+        message.certVerifier = certVerifier;
 
         Object selectedValue = getUserResponse(message);
 
diff -r 16a8b7bfee7d -r cde6d59a2901 netx/net/sourceforge/jnlp/tools/JarCertVerifier.java
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/netx/net/sourceforge/jnlp/tools/JarCertVerifier.java	Thu Apr 05 10:57:16 2012 -0400
@@ -0,0 +1,555 @@
+/*
+ * Copyright 1997-2007 Sun Microsystems, Inc.  All Rights Reserved.
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * This code is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.  Sun designates this
+ * particular file as subject to the "Classpath" exception as provided
+ * by Sun in the LICENSE file that accompanied this code.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara,
+ * CA 95054 USA or visit www.sun.com if you need additional information or
+ * have any questions.
+ */
+
+package net.sourceforge.jnlp.tools;
+
+import static net.sourceforge.jnlp.runtime.Translator.R;
+
+import java.io.*;
+import java.util.*;
+import java.util.jar.*;
+import java.security.cert.Certificate;
+import java.security.cert.X509Certificate;
+import java.security.cert.CertPath;
+import java.security.*;
+import sun.security.x509.*;
+import sun.security.util.*;
+
+import net.sourceforge.jnlp.*;
+import net.sourceforge.jnlp.cache.*;
+import net.sourceforge.jnlp.security.*;
+
+/**
+ * <p>The jar certificate verifier utility.
+ *
+ * @author Roland Schemers
+ * @author Jan Luehe
+ */
+
+public class JarCertVerifier implements CertVerifier {
+
+    private static final String META_INF = "META-INF/";
+
+    // prefix for new signature-related files in META-INF directory
+    private static final String SIG_PREFIX = META_INF + "SIG-";
+
+    private static final long SIX_MONTHS = 180 * 24 * 60 * 60 * 1000L; //milliseconds
+
+    static enum verifyResult {
+        UNSIGNED, SIGNED_OK, SIGNED_NOT_OK
+    }
+
+    // signer's certificate chain (when composing)
+    X509Certificate[] certChain;
+
+    boolean verbose = false; // verbose output when signing/verifying
+    boolean showcerts = false; // show certs when verifying
+
+    private boolean hasExpiredCert = false;
+    private boolean hasExpiringCert = false;
+    private boolean notYetValidCert = false;
+
+    private boolean badKeyUsage = false;
+    private boolean badExtendedKeyUsage = false;
+    private boolean badNetscapeCertType = false;
+
+    private boolean alreadyTrustPublisher = false;
+    private boolean rootInCacerts = false;
+
+    /**
+     * The single certPath used in this JarSiging. We're only keeping
+     * track of one here, since in practice there's only one signer
+     * for a JNLP Application.
+     */
+    private CertPath certPath = null;
+
+    private boolean noSigningIssues = true;
+
+    private boolean anyJarsSigned = false;
+
+    /** all of the jar files that were verified */
+    private ArrayList<String> verifiedJars = null;
+
+    /** all of the jar files that were not verified */
+    private ArrayList<String> unverifiedJars = null;
+
+    /** the certificates used for jar verification */
+    private HashMap<CertPath, Integer> certs = new HashMap<CertPath, Integer>();
+
+    /** details of this signing */
+    private ArrayList<String> details = new ArrayList<String>();
+
+    private int totalSignableEntries = 0;
+
+    /* (non-Javadoc)
+     * @see net.sourceforge.jnlp.tools.CertVerifier2#getAlreadyTrustPublisher()
+     */
+    public boolean getAlreadyTrustPublisher() {
+        return alreadyTrustPublisher;
+    }
+
+    /* (non-Javadoc)
+     * @see net.sourceforge.jnlp.tools.CertVerifier2#getRootInCacerts()
+     */
+    public boolean getRootInCacerts() {
+        return rootInCacerts;
+    }
+
+    public CertPath getCertPath() {
+        return certPath;
+    }
+
+    /* (non-Javadoc)
+     * @see net.sourceforge.jnlp.tools.CertVerifier2#hasSigningIssues()
+     */
+    public boolean hasSigningIssues() {
+        return hasExpiredCert || notYetValidCert || badKeyUsage
+                || badExtendedKeyUsage || badNetscapeCertType;
+    }
+
+    /* (non-Javadoc)
+     * @see net.sourceforge.jnlp.tools.CertVerifier2#noSigningIssues()
+     */
+    public boolean noSigningIssues() {
+        return noSigningIssues;
+    }
+
+    public boolean anyJarsSigned() {
+        return anyJarsSigned;
+    }
+
+    /* (non-Javadoc)
+     * @see net.sourceforge.jnlp.tools.CertVerifier2#getDetails()
+     */
+    public ArrayList<String> getDetails() {
+        return details;
+    }
+
+    /* (non-Javadoc)
+     * @see net.sourceforge.jnlp.tools.CertVerifier2#getCerts()
+     */
+    public ArrayList<CertPath> getCerts() {
+        return new ArrayList<CertPath>(certs.keySet());
+    }


From ddadacha at redhat.com  Thu Apr  5 07:59:32 2012
From: ddadacha at redhat.com (Danesh Dadachanji)
Date: Thu, 05 Apr 2012 10:59:32 -0400
Subject: [RFC][icedtea-web] Rename JarSigner to JarCertVerifier
In-Reply-To: <4F7CD021.1010700@redhat.com>
References: <4F7CC0A1.4000003@redhat.com> <4F7CD021.1010700@redhat.com>
Message-ID: <4F7DB354.3060602@redhat.com>

On 04/04/12 06:50 PM, Omair Majid wrote:
> On 04/04/2012 05:44 PM, Danesh Dadachanji wrote:
>> I propose a better name for it be JarCertVerifier. It implements
>> CertVerifier so I think following the trend (similarly to
>> HttpsCertVerifier) is a good idea.
>>
>> Any comments? Can I push to HEAD?
>
> The patch looks good to me.

Thanks for the fast review! Pushed here:

http://icedtea.classpath.org/hg/icedtea-web/rev/cde6d59a2901


From thomas at m3y3r.de  Thu Apr  5 08:17:47 2012
From: thomas at m3y3r.de (Thomas Meyer)
Date: Thu, 05 Apr 2012 17:17:47 +0200
Subject: [RFC] Fix IndexOutOfBoundException because of corrupted entry
	in recently_used file
In-Reply-To: <1333632651.6613.43.camel@localhost.localdomain>
References: <1332938501.1397.15.camel@localhost.localdomain>
	<4F79A620.2090702@redhat.com>
	<1333447622.5010.11.camel@localhost.localdomain>
	<4F7AE134.7080500@redhat.com>
	<1333458882.5010.14.camel@localhost.localdomain>
	<4F7B0E34.7010209@redhat.com>
	<1333551460.6613.13.camel@localhost.localdomain>
	<4F7D9742.4010608@redhat.com>
	<1333632651.6613.43.camel@localhost.localdomain>
Message-ID: <1333639067.6613.45.camel@localhost.localdomain>

Am Donnerstag, den 05.04.2012, 15:30 +0200 schrieb Thomas Meyer:
> > > --- a/netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java	Wed Mar 28 12:08:10 2012 +0200
> > > +++ b/netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java	Wed Apr 04 16:48:09 2012 +0200
> > > @@ -107,6 +107,49 @@
> > >        */
> > >       public synchronized void load() {
> > >           cacheOrder.load();
> > > +
> > > +        /*
> > > +         * clean up possibly corrupted entries
> > > +         */
> > It is interesting to see how many times is  checkData called during single jar run.. I counted 
> > 10executions.... But fixing this is definitely work for different patch.
> 
> yeah, I also noticed this. maybe this can be reduced a bit. see below
> comment for getCacheFile(). but as the recently_used file could be
> corrupted by another jvm process (etc.), we need to check this on every
> load.
> 

maybe the attached patch helps here?

with kind regards
thomas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: reduce-number-of-loads-and-stores.patch
Type: text/x-patch
Size: 2642 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120405/29783949/reduce-number-of-loads-and-stores.patch 

From stefan at complang.tuwien.ac.at  Thu Apr  5 13:11:31 2012
From: stefan at complang.tuwien.ac.at (Stefan Ring)
Date: Thu, 5 Apr 2012 22:11:31 +0200
Subject: PING: Copy CACAO's .hg repo as well with --with-cacao-src-dir
Message-ID: <CAAxjCEwaAjhMWoth70s=v-B7Z8--=2DCwHjH2BEqd90rhNJz=g@mail.gmail.com>

I've posted this a while ago:
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-March/017630.html

diff -r 54ceda20a02c Makefile.am
--- a/Makefile.am       Mon Feb 27 14:40:52 2012 +0100
+++ b/Makefile.am       Sat Mar 10 23:19:19 2012 +0100
@@ -997,8 +997,8 @@
        set -e ; \
        if ! test -d cacao ; \
        then \
-         mkdir -p cacao/cacao ; \
-         cp -r $(ALT_CACAO_SRC_DIR)/* cacao/cacao/ ; \
+         mkdir cacao ; \
+         cp -rL $(ALT_CACAO_SRC_DIR) cacao/cacao ; \
        fi
 else
        set -e ; \

The purpose is so that java -version is able to display version
information about CACAO as well, like this:
https://bitbucket.org/Ringdingcoder/cacao-dev/changeset/75b2b23e443c#comments

Because Mark asked about it in IRC, I added -L (--dereference) so it
works also if ALT_CACAO_SRC_DIR is a symlink. Since it works fine in
this case with the current version, I didn't want to break this
possibility.

Regards,
Stefan


From ddadacha at redhat.com  Thu Apr  5 13:50:56 2012
From: ddadacha at redhat.com (Danesh Dadachanji)
Date: Thu, 05 Apr 2012 16:50:56 -0400
Subject: [RFC][icedtea-web][JarCertVerifier Update] Remove/update useless
	variables
Message-ID: <4F7E05B0.5040901@redhat.com>

Hi,

When going through updates for JarCertVerifier, I stumbled across these to variables that don't serve much purpose. The two ArrayLists, 
verifiedJars and unverifiedJars contain the jars passed into JarCertVerifier that are either verified or unverified. However, the 
lists' contents are never read, except for in allJarsSigned().

To clarify, verifiedJars is never touched apart from declaration and adding contents so I propose we remove its unnecessary code 
altogether. Secondly, apart from initialization and adding contents, unverifiedJars is only read by the method mentioned above to check 
its size, let alone examine its contents. Since this is the case, an integer be a better fit for this variable. The attached patch does 
this.

I could not find them being read anywhere outside of JarCertVerifier so I think these changes should be acceptable. What does everyone 
else think?

ChangeLog:
+2012-04-05  Danesh Dadachanji  <ddadacha at redhat.com>
+
+	Update useless variables in JarCertVerifier.
+	* netx/net/sourceforge/jnlp/tools/JarCertVerifier.java:
+	Removed verifiedJars list, renamed unverifiedJars to numUnverifiedJars
+	and changed its type to int instead of ArrayList.
+


Cheers,
Danesh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: remove-useless-vars-in-jar-cert-verifier-01.patch
Type: text/x-patch
Size: 2129 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120405/891a8e12/remove-useless-vars-in-jar-cert-verifier-01.patch 

From jvanek at redhat.com  Fri Apr  6 02:55:18 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Fri, 06 Apr 2012 11:55:18 +0200
Subject: [RFC][icedtea-web] remove redundant loading/storing of cache file
	was : Re: [RFC] Fix IndexOutOfBoundException because of corrupted entry
	in recently_used file
In-Reply-To: <1333639067.6613.45.camel@localhost.localdomain>
References: <1332938501.1397.15.camel@localhost.localdomain>
	<4F79A620.2090702@redhat.com>
	<1333447622.5010.11.camel@localhost.localdomain>
	<4F7AE134.7080500@redhat.com>
	<1333458882.5010.14.camel@localhost.localdomain>
	<4F7B0E34.7010209@redhat.com>
	<1333551460.6613.13.camel@localhost.localdomain>
	<4F7D9742.4010608@redhat.com>
	<1333632651.6613.43.camel@localhost.localdomain>
	<1333639067.6613.45.camel@localhost.localdomain>
Message-ID: <4F7EBD86.6040402@redhat.com>

On 04/05/2012 05:17 PM, Thomas Meyer wrote:
> Am Donnerstag, den 05.04.2012, 15:30 +0200 schrieb Thomas Meyer:
>>>> >  >  >  --- a/netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java	Wed Mar 28 12:08:10 2012 +0200
>>>> >  >  >  +++ b/netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java	Wed Apr 04 16:48:09 2012 +0200
>>>> >  >  >  @@ -107,6 +107,49 @@
>>>> >  >  >          */
>>>> >  >  >         public synchronized void load() {
>>>> >  >  >             cacheOrder.load();
>>>> >  >  >  +
>>>> >  >  >  +        /*
>>>> >  >  >  +         * clean up possibly corrupted entries
>>>> >  >  >  +         */
>>> >  >  It is interesting to see how many times is  checkData called during single jar run.. I counted
>>> >  >  10executions.... But fixing this is definitely work for different patch.
>> >
>> >  yeah, I also noticed this. maybe this can be reduced a bit. see below
>> >  comment for getCacheFile(). but as the recently_used file could be
>> >  corrupted by another jvm process (etc.), we need to check this on every
>> >  load.
>> >
> maybe the attached patch helps here?
>
> with kind regards
> thomas
>
>
>
> reduce-number-of-loads-and-stores.patch
>
>
> diff -r 44a2eea54ac8 netx/net/sourceforge/jnlp/cache/CacheUtil.java
> --- a/netx/net/sourceforge/jnlp/cache/CacheUtil.java	Wed Apr 04 16:01:21 2012 +0200
> +++ b/netx/net/sourceforge/jnlp/cache/CacheUtil.java	Thu Apr 05 17:14:56 2012 +0200
> @@ -301,12 +301,18 @@
>           synchronized (lruHandler) {
>               lruHandler.lock();
>
> -            // We need to reload the cacheOrder file each time
> -            // since another plugin/javaws instance may have updated it.
> -            lruHandler.load();
>               cacheFile = getCacheFileIfExist(urlToPath(source, ""));
> +            if(cacheFile == null) { // We did not find a copy of it.
> +                // reload the cacheOrder file since another plugin/javaws instance may have updated it.
> +                lruHandler.load();
> +                cacheFile = getCacheFileIfExist(urlToPath(source, ""));
> +            }
> +
>               if (cacheFile == null) { // We did not find a copy of it.
> -                cacheFile = makeNewCacheFile(source, version);
> +                cacheFile = makeNewCacheFile(source, version, false);
> +            } else {
> +                // we did find and did update an entry, store it
> +                lruHandler.store();
>               }
>               lruHandler.unlock();
>           }
> @@ -360,10 +366,11 @@
>        * @param version the version id of the local file
>        * @return the file location in the cache.
>        */
> -    public static File makeNewCacheFile(URL source, Version version) {
> +    public static File makeNewCacheFile(URL source, Version version, boolean load) {
>           synchronized (lruHandler) {
>               lruHandler.lock();
> -            lruHandler.load();
> +            if(load == true)
> +                lruHandler.load();
>
>               File cacheFile = null;
>               for (long i = 0; i<  Long.MAX_VALUE; i++) {
> diff -r 44a2eea54ac8 netx/net/sourceforge/jnlp/cache/ResourceTracker.java
> --- a/netx/net/sourceforge/jnlp/cache/ResourceTracker.java	Wed Apr 04 16:01:21 2012 +0200
> +++ b/netx/net/sourceforge/jnlp/cache/ResourceTracker.java	Thu Apr 05 17:14:56 2012 +0200
> @@ -786,7 +786,7 @@
>                       entry.markForDelete();
>                       entry.store();
>                       // Old entry will still exist. (but removed at cleanup)
> -                    localFile = CacheUtil.makeNewCacheFile(resource.location, resource.downloadVersion);
> +                    localFile = CacheUtil.makeNewCacheFile(resource.location, resource.downloadVersion, true);
>                       CacheEntry newEntry = new CacheEntry(resource.location, resource.requestVersion);
>                       newEntry.lock();
>                       entry.unlock();
>


Hmm. As I see it, this is removing some load() but is adding store(). I think that in case of 
parallel javawss redundant reading does not hurt but more writing can hurt a lot.

 From my point of view I would rather stay without this fix - unless some more serious occurrences 
will rise from this issue.

Ok?

Best regards,
   J.


From jvanek at redhat.com  Fri Apr  6 03:01:19 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Fri, 06 Apr 2012 12:01:19 +0200
Subject: [RFC] Fix IndexOutOfBoundException because of corrupted entry
	in recently_used file
In-Reply-To: <1333632651.6613.43.camel@localhost.localdomain>
References: <1332938501.1397.15.camel@localhost.localdomain>
	<4F79A620.2090702@redhat.com>
	<1333447622.5010.11.camel@localhost.localdomain>
	<4F7AE134.7080500@redhat.com>
	<1333458882.5010.14.camel@localhost.localdomain>
	<4F7B0E34.7010209@redhat.com>
	<1333551460.6613.13.camel@localhost.localdomain>
	<4F7D9742.4010608@redhat.com>
	<1333632651.6613.43.camel@localhost.localdomain>
Message-ID: <4F7EBEEF.4070405@redhat.com>

On 04/05/2012 03:30 PM, Thomas Meyer wrote:
> Am Donnerstag, den 05.04.2012, 14:59 +0200 schrieb Jiri Vanek:
>> On 04/04/2012 04:57 PM, Thomas Meyer wrote:
>>> Am Dienstag, den 03.04.2012, 16:50 +0200 schrieb Jiri Vanek:
>>>>>   Thanx for test! Logic itself is good, but there are two mistakes which causes the test to be not-working.
>>>>>   See notes inline for them.
...
>>
>> However to print stacktrace just in debug mode will be probably better idea.
>> Plus information text I have dared to add.
>
> fine for me.
I have moved the exception to debug mode.
>
>>>
...
>>> +         * clean up possibly corrupted entries
>>> +         */
>> It is interesting to see how many times is  checkData called during single jar run.. I counted
>> 10executions.... But fixing this is definitely work for different patch.
>
> yeah, I also noticed this. maybe this can be reduced a bit. see below
> comment for getCacheFile(). but as the recently_used file could be
> corrupted by another jvm process (etc.), we need to check this on every
> load.
>
Fair enough
>>> +        if(checkData())

>>> -            lruHandler.store();
>> This scares me - why it have begin to be removed?
>
> in getCacheFile() method this happens:
>
> 1.) call load() ->  this must happen, because of concurrent update by
> other jvm processes.
> 2.) checks if entry exists
> 2a.) when yes ->  return the cacheFile entry
> 2b.) when no  ->  call makeNewCacheFile() ->  will call load() and
> store().
> 3.) call store() again ->  so this one can be omitted as the store will
> happen in makeNewCacheFile(), in already existing entry case, no store
> is needed.
> 4.) return cacheFile entry
>
> so here a superfluous store() is removed, as the store() will happen in

Thanx. Ok then.
> makeNewCacheFile() anyway. we may can get rid of the superfluous load()
> in makeNewCacheFile() in this case, too?
Hmmm... I don't think it is necessary
>

>>> -                    }
>>> +                assert(path!=null);
>> I'm not friend of assert(...)....
>
> I don't care about asserts(). They don't hurt as they are not active
> anyway.
>
>> I think this is even not necessary - the self-explaining NullPointerException will be thrown little
>> bit later. However I do not insists and do as you wish.
> Feel free to remove the asserts. I automatically write them in the code,
> because they don't really hurt.

Well.. I felt free to remove them. As you told  -- they should be not active O:)
>
>>> +
>>> +                if (pathToURLPath(path).equals(urlPath.getPath())) { // Match found.
>>> +                    cacheFile = new File(path);
>>> +                    lruHandler.updateEntry(key);
>>> +                    break; // Stop searching since we got newest one already.
>>>                    }
>>>                }
>>>                return cacheFile;
>>> @@ -561,10 +532,13 @@
>>>         * This will remove all old cache items.
>>>         */
>>>        public static void cleanCache() {
>>> +
>>>            if (okToClearCache()) {
>>>                // First we want to figure out which stuff we need to delete.
>>>                HashSet<String>   keep = new HashSet<String>();
>>>                HashSet<String>   remove = new HashSet<String>();
>>> +
>>> +            // FIXME: lock on recently_used file needed?
>>>                lruHandler.load();
>>
>> hmmm .. I do not know:(
>
> I guess it is not okay, as another javaws process could update the
> recently_used file concurrently, maybe nobody did hit this situation. I
> think the cleanChache() should be protected by a FileLock...

Ah! Now I see. This should be ok, because before cleaning always is checked whether another javaws 
is not running. If is, then no cleaning. So no lock should be necessary. If I'm right (and I think 
I'm then this comment should be removed)
>
>>>
>>>                long maxSize = -1; // Default
>>> @@ -579,57 +553,57 @@
>>>                for (Entry<String, String>   e : lruHandler.getLRUSortedEntries()) {
>>>                    // Check if the item is contained in cacheOrder.
>>>                    final String key = e.getKey();
>>> -                final String value = e.getValue();
>>> +                final String path = e.getValue();
>>>
>>> -                if (value != null) {
>>> -                    File file = new File(value);
>>> -                    PropertiesFile pf = new PropertiesFile(new File(value + ".info"));
>>> -                    boolean delete = Boolean.parseBoolean(pf.getProperty("delete"));
>>> +                assert(path!=null);
>> same assert as above...?...
> yes. path must be not null here.

And it isn't O:)
>
>>>
...
>>> -                    lruHandler.removeEntry(key);
>>> +
>>>                    }
>>
>> I must admit that I did not got fully the meaning of this change. But it is working pretty fine and
>> looks ok :)
>
> the idea is to remove the check for "if(path != null)", as we did
> already make sure in load()->checkData() that the path is not null.
> that's all.

yap. Fair enough.
>
>>>                }
>>>                lruHandler.store();
>>> diff -r 093896b370d3 netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java
>>> --- a/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java	Wed Mar 28 12:08:10 2012 +0200
>>> +++ b/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java	Wed Apr 04 16:48:09 2012 +0200
>>> @@ -713,6 +713,7 @@
>>>            Runtime.getRuntime().addShutdownHook(new Thread() {
>>>                public void run() {
>>>                    markNetxStopped();
>>> +                // no lock on recently_used file needed?
>> I'm not sure again as above :(
>>>                    CacheUtil.cleanCache();
>>>                }
>>>            });
>>>
>>
>> I hope my small changes will not insult you, but while I was playing with your changeset they looks
>> to me like essential ones so I put them in instead of describing.
>
> I couldn't see any insults in this mail :-) Just good improvements to me
> patch.
>
>>
>> If you will agree with printing of lrucacheexception stacktrace then this is nearly done.
> Im' fine with the printing.
>
>> If you will insists on no stacktreace printing or (what I prefer) on printing it out just in debug
>> mode, then the tests will need little fixing. (for case with no stacktraces it will need to change
>> testing conditions, and for stacktace printed in debugmode it will need to run javaws in verbose mode)
>>
Print stacktrace moved to debug mode. In normal mode just user-friendly messages printed out. Test 
modified accordingly.


If You are ok with current state, please update changelog and push. If You do not have still push 
access, you can approve me to push in your name.


Best regards
J.


2012-06-04  Jiri Vanek <jvanek at redhat.com>
			Thomas Meyer <thomas at m3y3r.de>

	* makefile.am: (stamps/run-netx-dist-tests.stamp) and (run-reproducers-test-code-coverage.stamp)
	now using $(javaws) variable instead of plaintext javaws
	* netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java: (checkData) new
	method checking for sanity of cache entries
	(load) now checks for data sanity after loading, and stores without
	corrupted items if necessary
	(Comparator.compare) for sorting lru items. Now redundant checking for
	sanity removed
	* netx/net/sourceforge/jnlp/cache/CacheUtil.java: (getCacheFile) removed
	redundant lruHandler.store call
	(getCacheFileIfExist) removed iteration and cleaning mechanism
	* netx/net/sourceforge/jnlp/resources/Messages.properties: modified
	cache messages
	* tests/jnlp_tests/signed/CacheReproducer/testcases/CacheReproducerTest.java
	Added test for checking corrupted path in entry and all tests adapted for
	exception thrown only in debug mode	
-------------- next part --------------
A non-text attachment was scrubbed...
Name: thomasImprovedCacheFix2.diff
Type: text/x-patch
Size: 24780 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120406/8f880544/thomasImprovedCacheFix2.diff 

From ptisnovs at icedtea.classpath.org  Fri Apr  6 04:01:22 2012
From: ptisnovs at icedtea.classpath.org (ptisnovs at icedtea.classpath.org)
Date: Fri, 06 Apr 2012 11:01:22 +0000
Subject: /hg/gfx-test: * src/org/gfxtest/common/Configuration.java:
Message-ID: <hg.0594d3a7c745.1333710082.-6248649288953172555@icedtea.classpath.org>

changeset 0594d3a7c745 in /hg/gfx-test
details: http://icedtea.classpath.org/hg/gfx-test?cmd=changeset;node=0594d3a7c745
author: Pavel Tisnovsky <ptisnovs at redhat.com>
date: Fri Apr 06 13:03:55 2012 +0200

	* src/org/gfxtest/common/Configuration.java:
		* src/org/gfxtest/common/ConfigurationException.java:
		* src/org/gfxtest/common/InvalidParameterValueException.java:
		Code and JavaDoc improvements.


diffstat:

 ChangeLog                                                  |   7 ++
 src/org/gfxtest/common/Configuration.java                  |  39 +++++++++++--
 src/org/gfxtest/common/ConfigurationException.java         |  22 +++++++-
 src/org/gfxtest/common/InvalidParameterValueException.java |  15 ++++-
 4 files changed, 71 insertions(+), 12 deletions(-)

diffs (227 lines):

diff -r b26c11e47283 -r 0594d3a7c745 ChangeLog
--- a/ChangeLog	Wed Apr 04 11:57:23 2012 +0200
+++ b/ChangeLog	Fri Apr 06 13:03:55 2012 +0200
@@ -1,3 +1,10 @@
+2012-04-05  Pavel Tisnovsky  <ptisnovs at redhat.com>
+
+	* src/org/gfxtest/common/Configuration.java:
+	* src/org/gfxtest/common/ConfigurationException.java:
+	* src/org/gfxtest/common/InvalidParameterValueException.java:
+	Code and JavaDoc improvements.
+
 2012-04-04  Pavel Tisnovsky  <ptisnovs at redhat.com>
 
 	* src/org/gfxtest/testsuites/ClippingCircleByRoundRectangleShape.java:
diff -r b26c11e47283 -r 0594d3a7c745 src/org/gfxtest/common/Configuration.java
--- a/src/org/gfxtest/common/Configuration.java	Wed Apr 04 11:57:23 2012 +0200
+++ b/src/org/gfxtest/common/Configuration.java	Fri Apr 06 13:03:55 2012 +0200
@@ -1,7 +1,7 @@
 /*
   Java gfx-test framework
 
-   Copyright (C) 2010, 2011  Red Hat
+   Copyright (C) 2010, 2011, 2012  Red Hat
 
 This file is part of IcedTea.
 
@@ -50,7 +50,7 @@
 
 /**
  * This class is used to store actual configuration of graphics test framework.
- * Configuration can be changed via command line switches.
+ * Configuration can be changed via various command line switches.
  * 
  * @author Pavel Tisnovsky
  */
@@ -62,7 +62,7 @@
     protected Log log;
 
     /**
-     * Constructor called with array containing command line arguments.
+     * Constructor called with an array containing command line arguments.
      * 
      * @param args
      *            command line arguments
@@ -80,26 +80,42 @@
         printParameters();
     }
 
+    /**
+     * Implementation of this abstract method should reads and process all
+     * command line parameters.
+     * 
+     * @param args
+     *            command line arguments
+     */
     protected abstract void readCommandLineParameters(String[] args) throws ConfigurationException;
+
+    /**
+     * Implementation of this abstract method should prints all test suite
+     * parameters.
+     */
     protected abstract void printParameters();
 
     /**
-     * Method for get value of parameter which has integer value.
+     * Method for get value of parameter which has an integer type.
      * 
      * @param options
-     *            map containing all parameters
+     *            map containing all configuration parameters
      * @param parameterName
      *            parameter name
      * @return integer value of selected parameter
      * @throws ConfigurationException
+     *             thrown if parameter is not found or has wrong value
      */
     protected int getIntegerParameter(Map<String, String> options, String parameterName) throws ConfigurationException
     {
+        // check if parameter map contains parameter with given name
         if (!options.containsKey(parameterName))
         {
             throw new ParameterNotFoundException(parameterName);
         }
+        // get a value of a parameter
         String parameterValue = options.get(parameterName);
+        // and parse it as integer
         try
         {
             return Integer.parseInt(parameterValue);
@@ -111,18 +127,20 @@
     }
 
     /**
-     * Method for get value of parameter which has string value.
+     * Method for get value of parameter which has a string type.
      * 
      * @param options
-     *            map containing all parameters
+     *            map containing all configuration parameters
      * @param parameterName
      *            parameter name
      * @return string value of selected parameter
      * @throws ConfigurationException
+     *             thrown if parameter is not found or has wrong value
      */
     protected String getStringParameter(Map<String, String> options, String parameterName)
                     throws ConfigurationException
     {
+        // check if parameter map contains parameter with given name
         if (!options.containsKey(parameterName))
         {
             throw new ParameterNotFoundException(parameterName);
@@ -134,20 +152,25 @@
      * Resolve all configuration options, ie. parse it and push it to a map.
      * 
      * @param args
-     *            command line parameters
+     *            command line arguments
      * @return map containing all parameters
      */
     @SuppressWarnings("nls")
     protected Map<String, String> resolveAllOptions(String[] args)
     {
         Map<String, String> options = new HashMap<String, String>();
+        // loop over all command line arguments
         for (String arg : args)
         {
+            // quick and dirty parsing of command line parameters
+            // param is split at '=' symbol
             String[] splittedArg = arg.split("=");
             if (splittedArg.length >= 1 && splittedArg[0].length() >= 2)
             {
                 this.log.log("found option " + arg);
+                // get parameter name
                 String optionName = splittedArg[0].substring(1);
+                // get parameter value
                 String optionValue = splittedArg.length == 2 ? splittedArg[1] : "true";
                 options.put(optionName, optionValue);
             }
diff -r b26c11e47283 -r 0594d3a7c745 src/org/gfxtest/common/ConfigurationException.java
--- a/src/org/gfxtest/common/ConfigurationException.java	Wed Apr 04 11:57:23 2012 +0200
+++ b/src/org/gfxtest/common/ConfigurationException.java	Fri Apr 06 13:03:55 2012 +0200
@@ -1,7 +1,7 @@
 /*
   Java gfx-test framework
 
-   Copyright (C) 2010, 2011  Red Hat
+   Copyright (C) 2010, 2011, 2012  Red Hat
 
 This file is part of IcedTea.
 
@@ -40,19 +40,37 @@
 
 package org.gfxtest.common;
 
+
+
 /**
+ * This exception is thrown in case of any configuration problem.
  * 
  * @author Pavel Tisnovsky
  */
 public abstract class ConfigurationException extends Exception
 {
     /**
-     * Generated serial version ID
+     * Generated serial version ID.
      */
     private static final long serialVersionUID = -2168810923554713703L;
 
+    /**
+     * Disable implicit constructor.
+     */
+    @SuppressWarnings("unused")
+    private ConfigurationException()
+    {
+        // empty
+    }
+
+    /**
+     * Constructor for this type of exception.
+     *
+     * @param message the detail message
+     */
     public ConfigurationException(String message)
     {
+        // simply pass detail message
         super(message);
     }
 }
diff -r b26c11e47283 -r 0594d3a7c745 src/org/gfxtest/common/InvalidParameterValueException.java
--- a/src/org/gfxtest/common/InvalidParameterValueException.java	Wed Apr 04 11:57:23 2012 +0200
+++ b/src/org/gfxtest/common/InvalidParameterValueException.java	Fri Apr 06 13:03:55 2012 +0200
@@ -41,20 +41,31 @@
 package org.gfxtest.common;
 
 
+
 /**
+ * This exception is thrown when any configuration parameter (specified on
+ * command line) has wrong value.
  * 
  * @author Pavel Tisnovsky
  */
 public class InvalidParameterValueException extends ConfigurationException
 {
     /**
-     * Genereated serial version ID.
+     * Generated serial version ID.
      */
     private static final long serialVersionUID = 3027080845460577282L;
 
+    /**
+     * Constructor for this type of exception.
+     * 
+     * @param parameterName
+     *            name of parameter which has wrong value
+     * @param value
+     *            (wrong) value of parameter specified on command line
+     */
     public InvalidParameterValueException(String parameterName, String value)
     {
+        // create and pass detail message
         super("invalid value of parameter " + parameterName + ": " + value); //$NON-NLS-1$ //$NON-NLS-2$
     }
-
 }


From jvanek at redhat.com  Fri Apr  6 05:56:35 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Fri, 06 Apr 2012 14:56:35 +0200
Subject: [rfc] [icedtea-web] blacklist for reproducers
Message-ID: <4F7EE803.4060401@redhat.com>

Hi!

This is second from total of 5 patches which are introducing Tets For Applets[1]

Thus particular one is introducing  blacklist. The test-engine is delivered to class-path together 
with all reproducers' testcases. If the file form engine is interface, have no @Test methods or does 
not meet constructor requirements, then the file fails, and this is making our statistics misleading.
Also I'm expecting growing of engine (now I'm planing @bug and @browser annotations and some more 
logic around. See content of ignore-list after all this changes[2]. Also I would like to refactor 
ServerAccess class little bit in long term (as it have grown littlebit and have to much inner 
classes right now) future...

Probably cleaner solution will be to separate testengine from testaces more then it is now, but I 
have tried this refactoring and I was getting deeper and deeper and it was bringing more and more 
issues. From this I'm really for blacklist rather then for refactoring.
Also one more benefit is here - you can easili blacklist all reproducers except one or two fro make ;)

Best regards J.

[1] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-March/017799.html
[2] 
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120320/8ef6bdfe/browserTests-blacklist-0001.diff


From ahughes at redhat.com  Fri Apr  6 06:01:06 2012
From: ahughes at redhat.com (Andrew Hughes)
Date: Fri, 06 Apr 2012 09:01:06 -0400 (EDT)
Subject: PING: Copy CACAO's .hg repo as well with --with-cacao-src-dir
In-Reply-To: <CAAxjCEwaAjhMWoth70s=v-B7Z8--=2DCwHjH2BEqd90rhNJz=g@mail.gmail.com>
Message-ID: <7b353042-98ba-448f-8160-dcf6a17960d0@zmail17.collab.prod.int.phx2.redhat.com>

----- Original Message -----
> I've posted this a while ago:
> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-March/017630.html
> 
> diff -r 54ceda20a02c Makefile.am
> --- a/Makefile.am       Mon Feb 27 14:40:52 2012 +0100
> +++ b/Makefile.am       Sat Mar 10 23:19:19 2012 +0100
> @@ -997,8 +997,8 @@
>         set -e ; \
>         if ! test -d cacao ; \
>         then \
> -         mkdir -p cacao/cacao ; \
> -         cp -r $(ALT_CACAO_SRC_DIR)/* cacao/cacao/ ; \
> +         mkdir cacao ; \
> +         cp -rL $(ALT_CACAO_SRC_DIR) cacao/cacao ; \
>         fi
>  else
>         set -e ; \
> 
> The purpose is so that java -version is able to display version
> information about CACAO as well, like this:
> https://bitbucket.org/Ringdingcoder/cacao-dev/changeset/75b2b23e443c#comments
> 
> Because Mark asked about it in IRC, I added -L (--dereference) so it
> works also if ALT_CACAO_SRC_DIR is a symlink. Since it works fine in
> this case with the current version, I didn't want to break this
> possibility.
> 
> Regards,
> Stefan
> 

Thanks Stefan.  I guess we missed this with it being posted on a weekend.  Sorry
about that.

I'll add the fix to 6, 7 & 8 HEAD on your behalf (do you have commit access?)
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From stefan at complang.tuwien.ac.at  Fri Apr  6 06:06:33 2012
From: stefan at complang.tuwien.ac.at (Stefan Ring)
Date: Fri, 6 Apr 2012 15:06:33 +0200
Subject: PING: Copy CACAO's .hg repo as well with --with-cacao-src-dir
In-Reply-To: <7b353042-98ba-448f-8160-dcf6a17960d0@zmail17.collab.prod.int.phx2.redhat.com>
References: <CAAxjCEwaAjhMWoth70s=v-B7Z8--=2DCwHjH2BEqd90rhNJz=g@mail.gmail.com>
	<7b353042-98ba-448f-8160-dcf6a17960d0@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <CAAxjCEyPDp+2KeDQbbp6ze0ZW6BJ6sicdQTHzqYcSFmEt5BDXg@mail.gmail.com>

> Thanks Stefan. ?I guess we missed this with it being posted on a weekend. ?Sorry
> about that.

No problem ;).

> I'll add the fix to 6, 7 & 8 HEAD on your behalf (do you have commit access?)

Thanks. No, I don't.


From ahughes at redhat.com  Fri Apr  6 06:46:20 2012
From: ahughes at redhat.com (Andrew Hughes)
Date: Fri, 06 Apr 2012 09:46:20 -0400 (EDT)
Subject: PING: Copy CACAO's .hg repo as well with --with-cacao-src-dir
In-Reply-To: <CAAxjCEyPDp+2KeDQbbp6ze0ZW6BJ6sicdQTHzqYcSFmEt5BDXg@mail.gmail.com>
Message-ID: <b35adfca-11e3-4241-a545-69836e661d69@zmail17.collab.prod.int.phx2.redhat.com>

----- Original Message -----
> > Thanks Stefan. ?I guess we missed this with it being posted on a
> > weekend. ?Sorry
> > about that.
> 
> No problem ;).
> 
> > I'll add the fix to 6, 7 & 8 HEAD on your behalf (do you have
> > commit access?)
> 
> Thanks. No, I don't.

Ok, you should ping mjw after the holidays to get access :-)

> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From jvanek at redhat.com  Fri Apr  6 06:51:20 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Fri, 06 Apr 2012 15:51:20 +0200
Subject: [rfc] [icedtea-web] blacklist for reproducers
In-Reply-To: <4F7EE803.4060401@redhat.com>
References: <4F7EE803.4060401@redhat.com>
Message-ID: <4F7EF4D8.3020300@redhat.com>

missing patch. Sorry.
On 04/06/2012 02:56 PM, Jiri Vanek wrote:
> Hi!
>
> This is second from total of 5 patches which are introducing Tets For Applets[1]
>
> Thus particular one is introducing blacklist. The test-engine is delivered to class-path together
> with all reproducers' testcases. If the file form engine is interface, have no @Test methods or does
> not meet constructor requirements, then the file fails, and this is making our statistics misleading.
> Also I'm expecting growing of engine (now I'm planing @bug and @browser annotations and some more
> logic around. See content of ignore-list after all this changes[2]. Also I would like to refactor
> ServerAccess class little bit in long term (as it have grown littlebit and have to much inner
> classes right now) future...
>
> Probably cleaner solution will be to separate testengine from testaces more then it is now, but I
> have tried this refactoring and I was getting deeper and deeper and it was bringing more and more
> issues. From this I'm really for blacklist rather then for refactoring.
> Also one more benefit is here - you can easili blacklist all reproducers except one or two fro make ;)
>
> Best regards J.
>
> [1] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-March/017799.html
> [2]
> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120320/8ef6bdfe/browserTests-blacklist-0001.diff
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: reproducersBlackist.diff
Type: text/x-patch
Size: 1519 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120406/29ce1f3c/reproducersBlackist.diff 

From jvanek at redhat.com  Fri Apr  6 07:55:04 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Fri, 06 Apr 2012 16:55:04 +0200
Subject: [rfc] [icedtea-web] make links
Message-ID: <4F7F03C8.6070605@redhat.com>

Hi!

This is third from total of 5 patches which are introducing Tets For Applets[1]

This particular one is introducing  detection of browsers, linking the newly compiled plugin to 
detected ones and forwarding this information to testengine..

I know this linking by makefile is controversial, but it gives sense to me.
Yes  - I can link the plugin with browsers manually before tests' run (and yes, this can be done 
once for all the runs in future), but I think this is much more versatile and is much more 
straightforward and much better controllable and also more fool-proof. The question weather to 
*UNlink* is more accurate:) ( there is no unlink right now, but should be easily addable if requested.
Also when tests are run from makefile, then also all the possible preparation should be done from 
makefile. And this step is necessary. I have also introduced test weather linking is correct see 
private void testBrowser(Browser browser) calls in [2]

What I'm missing is When I have choose AC_CHECK_PROGS, then it does not support --with-val :-/ Is 
there any AC_CHECK_PROGS which allows to set with-val?
Becasue I will probably put rather --with-firefox=/my/preconfiguired/firefox instead of let it use 
my default one. Although Lynks is quite good alternative during tests runtime :)
Also this can be maybe intorduced as new patch later.

Best regards J.

[1] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-March/017799.html
[2] 
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120320/8ef6bdfe/browserTests-tests-0001.diff 
(btw, this page is partially corrupted - there is html test, and firefox is trying to translate it 
as html page :-/.. so see source rather :-/)


changelog:
2012-04-06  Jiri Vanek <jvanek at redhat.com>

	Added detection of installed browsers and added targets to create symbolic links from install dir
to browsers' plugin directories. Primarily for testing purposes
	*Makefile.am: (clean-local) optionally delets links' stamps
	(stamps/user-links.stamp) with alias (links) - new target for creating symlinks for all users. One
must be root to execute this target.
	(stamps/global-links.stamp) with alias (user-links) - new target for creating symlinks for logged
user only. Because opera is missing this feature, quite useless.
	*configure.ac: added basic check whether and which browsers are installed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: makeLinks.diff
Type: text/x-patch
Size: 5211 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120406/43d080ff/makeLinks.diff 

From ptisnovs at redhat.com  Fri Apr  6 08:24:34 2012
From: ptisnovs at redhat.com (Pavel Tisnovsky)
Date: Fri, 06 Apr 2012 17:24:34 +0200
Subject: [rfc][icedtea-web] rewritten xfork test
In-Reply-To: <4F6B1821.2040600@redhat.com>
References: <4F6B1821.2040600@redhat.com>
Message-ID: <4F7F0AB2.8070201@redhat.com>

Jiri Vanek wrote:
> Inspired by Omair's effort to reduce failing tests, I have rewritten
> deadlock tests, which were failing quite randomly in half of the cases.
> It was caused by delayed removing of zombies after process have time-outed.
> 
> By this patch, ignorelist which I have proposed two days ago (and will
> do again soon as separate patch) to ignore no-testable classes (eg 
> interfaces), and fixes from [RFC][icedtea-web] fixes to reproducer
> engine, we will be on three  failing reproducers ("spaces" ) and  with
> occasional cache test fill.
> 
> All those five -  two sometimes, three regularly - failing reproducers
> are the same issue we are talking  in [icedtea-web] RFC: disable tests
> that are known to fail thread. - they are representing issue., but...:)
> 
> 
> 
> 2012-03-22  Jiri Vanek <jvanek at redhat.com>
> 
>     Rewritten DeadLockTestTest to stop failing in more then 1/2 of cases
>     All assassinated processes were hanging as zombies, killed forcibly by
>     kill -9 now.
>     *
> /tests/jnlp_tests/simple/deadlocktest/testcases/DeadLockTestTest.java:
>     (countJavaInstances) now return pids of found javas.
>     (killDiff) new method killing zombie javas forcibly.
> 

Hi Jiri,

could you please fix following typos in the test tool?

"This process is hanging more th_e_n"

"...but isnt!"
          ^    (on more places)

"proces inside background deadlock cant be null. Was."
                                     ^           It ^

"lunched JVMs must be exactly 2"
  ^  (this one is funny :-)


Thank you in advance,
Pavel


From jvanek at redhat.com  Fri Apr  6 08:31:39 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Fri, 06 Apr 2012 17:31:39 +0200
Subject: [fyi] [icedtea-web] xmx for emma
Message-ID: <4F7F0C5B.6090500@redhat.com>

Hi! Recently codecoverage have fallen on my test machines because of not enough heap space. I would 
like to increase its Xmx value (eg to 2g as I'm doing in this patch)

Best regards, J

changelog:

2012-04-06  Jiri Vanek <jvanek at redhat.com>

	jvms running emma enlarged max heap space
	* Makefile.am: (stamps/run-unit-test-code-coverage.stamp), 
(stamps/run-reproducers-test-code-coverage.stamp) and (run-test-code-coverage) java emma calls have 
increased theirs -Xmx value
-------------- next part --------------
A non-text attachment was scrubbed...
Name: emmaXmx.diff
Type: text/x-patch
Size: 2581 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120406/7a430f39/emmaXmx.diff 

From andrew at icedtea.classpath.org  Fri Apr  6 12:53:14 2012
From: andrew at icedtea.classpath.org (andrew at icedtea.classpath.org)
Date: Fri, 06 Apr 2012 19:53:14 +0000
Subject: /hg/icedtea7: 2 new changesets
Message-ID: <hg.ab3f4766a208.1333741994.2873452341184383833@icedtea.classpath.org>

changeset ab3f4766a208 in /hg/icedtea7
details: http://icedtea.classpath.org/hg/icedtea7?cmd=changeset;node=ab3f4766a208
author: Andrew John Hughes <ahughes at redhat.com>
date: Fri Apr 06 18:28:57 2012 +0100

	Support glib >= 2.32.

	2012-04-06  Andrew John Hughes  <ahughes at redhat.com>

		* acinclude.m4:
		(IT_CHECK_FOR_GTK): Work with glib >= 2.32
		by explicitly asking for gthread.


changeset d9400e955e0f in /hg/icedtea7
details: http://icedtea.classpath.org/hg/icedtea7?cmd=changeset;node=d9400e955e0f
author: Andrew John Hughes <ahughes at redhat.com>
date: Fri Apr 06 20:52:28 2012 +0100

	Include generalised crypto tests.

	2012-04-06  Andrew John Hughes  <ahughes at redhat.com>

		* Makefile.am:
		(JDK_CHANGESET): Bump to include generalied crypto tests.
		(JDK_SHA256SUM): Likewise.


diffstat:

 ChangeLog    |  12 ++++++++++++
 Makefile.am  |   4 ++--
 acinclude.m4 |   2 +-
 3 files changed, 15 insertions(+), 3 deletions(-)

diffs (52 lines):

diff -r 75954b8de67b -r d9400e955e0f ChangeLog
--- a/ChangeLog	Tue Mar 27 14:06:49 2012 +0200
+++ b/ChangeLog	Fri Apr 06 20:52:28 2012 +0100
@@ -1,3 +1,15 @@
+2012-04-06  Andrew John Hughes  <ahughes at redhat.com>
+
+	* Makefile.am:
+	(JDK_CHANGESET): Bump to include generalied crypto tests.
+	(JDK_SHA256SUM): Likewise.
+
+2012-04-06  Andrew John Hughes  <ahughes at redhat.com>
+
+	* acinclude.m4:
+	(IT_CHECK_FOR_GTK): Work with glib >= 2.32
+	by explicitly asking for gthread.
+
 2012-03-27  Mark Wielaard  <mjw at redhat.com>
 
 	* patches/systemtap.patch: Rewrite using just USDT1 with macros
diff -r 75954b8de67b -r d9400e955e0f Makefile.am
--- a/Makefile.am	Tue Mar 27 14:06:49 2012 +0200
+++ b/Makefile.am	Fri Apr 06 20:52:28 2012 +0100
@@ -8,7 +8,7 @@
 HOTSPOT_CHANGESET = b1dfb460ee5c
 JAXP_CHANGESET = 9b7a2f21b8a8
 JAXWS_CHANGESET = 9ae185bd7ff2
-JDK_CHANGESET = 3377516da583
+JDK_CHANGESET = a1fe26be9fab
 LANGTOOLS_CHANGESET = 54b1383d794c
 OPENJDK_CHANGESET = 3a0fd3cc84a0
 
@@ -16,7 +16,7 @@
 HOTSPOT_SHA256SUM = 43d83d5209a9f748e6650c792ca8ef8d9a90d6e3c53e461993c6bffb8c37e972
 JAXP_SHA256SUM = 4d38e8a0fc0fcbe3ba8a56f9fc0960ecbf15cd4cef44b76fdc82418c008a33c3
 JAXWS_SHA256SUM = 60c6c62c851eafc15ff33e58aa625e6f58fd31f15328b121602a07891fc1d272
-JDK_SHA256SUM = 5707d697c2dfc44fbf91ec90721055b5a23ea4c77f0cb53abf00a0f53fa0845e
+JDK_SHA256SUM = 8455cc8888eaaba420a0a37ed1d76b73b7b67dcade3c856626f9ce82e1fc2408
 LANGTOOLS_SHA256SUM = 97821e49028d8d726fac9563c361c682146e037074179cbd68ed5cb80e82f9fa
 OPENJDK_SHA256SUM = abe0c3b348c35f79117ef726bb2580b279024b1f73b6487fda4a1e717c738f9f
 
diff -r 75954b8de67b -r d9400e955e0f acinclude.m4
--- a/acinclude.m4	Tue Mar 27 14:06:49 2012 +0200
+++ b/acinclude.m4	Fri Apr 06 20:52:28 2012 +0100
@@ -2011,7 +2011,7 @@
   AC_MSG_RESULT(${ENABLE_SYSTEM_GTK})
   if test x"${ENABLE_SYSTEM_GTK}" = "xyes"; then
     dnl Check for Gtk+ headers and libraries.
-    PKG_CHECK_MODULES(GTK, gtk+-2.0,[GTK_FOUND=yes],[GTK_FOUND=no])
+    PKG_CHECK_MODULES(GTK, gtk+-2.0 gthread-2.0,[GTK_FOUND=yes],[GTK_FOUND=no])
     if test "x${GTK_FOUND}" = xno
     then
       AC_MSG_ERROR([Could not find Gtk+; install Gtk+ or build with --disable-system-gtk to use the in-tree headers.])


From ddadacha at redhat.com  Fri Apr  6 14:57:22 2012
From: ddadacha at redhat.com (Danesh Dadachanji)
Date: Fri, 06 Apr 2012 17:57:22 -0400
Subject: [RFC][icedtea-web] Unit tests for the new updates to JarSIgner
	(incomplete)
In-Reply-To: <4F7CDAF7.6090503@redhat.com>
References: <4F7A1037.7060405@redhat.com> <4F7CDAF7.6090503@redhat.com>
Message-ID: <4F7F66C2.8060506@redhat.com>

Hi Omair,

Thanks for the review!

On 04/04/12 07:36 PM, Omair Majid wrote:
> Hi Danesh,
>
> On 04/02/2012 04:46 PM, Danesh Dadachanji wrote:
>> I've been working on updating JarSigner to be able to handle multiple
>> signers properly. Currently, it mashes and saves all of the signers'
>> properties (flags for expired/badly signed/not yet valid) as one. In
>> other words, if one signer has expired, all signers are seen by
>> IcedTea-Web as expired. If one has signing issues, then they all have
>> signing issues. This is definitely not an ideal solution since we're
>> telling users that verifiable applications are not verified.
>>
>> The attached patch contains a set of unit tests for the (former)
>> verifyJar method. I'm going to avoid including the actual code for these
>> changes just yet because the entire class isn't fully cleaned up. Here's
>> a bit of background info on what I've changed though.
>>
>>
>> * What verifyJar should be doing:
>>
>> My understanding of the idea behind verifyJar is that it does 2 somewhat
>> separate tasks. First, given a jar, iterate over all of its entries. For
>> every entry that can be signed, go through the list of signers and see
>> if any have issues. If they do, setup the flags accordingly (issues
>> could be expiry/bad key usage/not yet valid start date etc). Also, keep
>> track of the number of entries each signer has signed, as well as the
>> total number of possible signable entries. The second step is going
>> through all of the signers after all the entries have been iterated over
>> to see if there is a common signer that has signed them all. If there is
>> any entry that is not signed but should be, or if there is one entry
>> that does not share a common signer between all other entries, then this
>> jar is considered UNSIGNED. If all entries (that should be signed) share
>> a common signer, then the signer itself is checked. If the signer has
>> signing issues, the jar is considered SIGNED_NOT_OKAY, if it has no
>> signing issues, the jar is considered SIGNED_OK.
>>
>
> This does make sense to me. Something that sort of jumps out at me is
> that these two responsibilities are fairly distinct. It seems like it
> might be worth it to split it into two distinct objects, each taking
> care of one responsibility. That is, one objects determines if it should
> be considered signed or unsigned, and another checks that (if signed)
> the signing certificate is good.
>

Hmm interesting idea, it makes sense to separate the checking/setup of the signers and the checking of the jar. However, I would like 
to get back to you on this once I have wondered into the mess that is verifyJars(). I think there is definitely potential here to move 
bits into another class but I don't fully know what is needed by the rest of JarCertVerifier. Until I do, I would rather avoid 
refactoring this until it is needed.

>> * Summary of my changes to verifyJar:
>>
>> I've split verifyJar into 2 methods, all the logic/implementations from
>> line 265[1] and onwards is now in a method named verifyJarEntryCerts.
>> Here's a quick snippet of its javadoc and method declaration:
>>
>>      /**
>>       * Checks through all the jar entries for signers, storing all the
>> common
>>       * ones in the certs hash map.
>>       * @param jarHasManifest Whether or not the associated jar has a
>> manifest.
>>       * @param entries The list of entries in the associated jar.
>>       * @return If there is at least one signable entry that is not
>> signed by a
>>       * common signer, return UNSIGNED. Otherwise every signable entry is
>>       * signed by at least one common signer. If the signer has no issues,
>>       * return SIGNED_OK. If there are any signing issues, return
>> SIGNED_NOT_OK.
>>       * @throws Exception Will be thrown if there are issues with entries.
>>       */
>>      VerifyResult verifyJarEntryCerts(boolean jarHasManifest,
>> Vector<JarEntry>  entries) throws Exception
>>
>> The reason I've split this method up is so that JarSigner can be made
>> unit testable. The method verifyJar takes in a jar name and
>> creating/commiting one to upstream isn't suitable. Instead, I've created
>> an extra helper method that takes in a list of jar entries and tests
>> everything the original code tests. The new unit test class then hard
>> codes these entries, along with their signers, to make this method
>> testable.
>
> Good stuff!
>

Thanks!

>> For the entries' signers, I've created a helper class that creates
>> X509Certificate objects with specified domain names/start dates/validity
>> periods. This code is essentially taken from
>> sun.security.tools.KeyTool#doGenKeyPair (which calls
>> KeyTool#doSelfCert), I've removed the bits that aren't needed
>> (KeyStore/alias etc) and left the bare minimum that is needed to create
>> an X509Certificate. I'm not 100% sure of the copyright header that is
>> needed for this class so I used the same one provided by KeyTool from
>> here [2] (with s/2011/2012). I would appreciate any insight as to if
>> this is correct. =)
>
> IANAL. That said, you should note all the copyright owners. I believe
> that would be Oracle (since they own the original code in KeyTool), and
> Red Hat (since that's who owns the newer/modified code). Since both
> Oracle and Red Hat have licensed the code under GPLv2+Classpath, it
> should be okay to replace this version of the header with the one more
> commonly used in icedtea-web (they do refer to the same license after all).
>
>> The unit tests themselves are pretty self-explanatory, to save on
>> space/repetition, I've kept testing 1 entry and then 3 entries with the
>> same scenario under one method (with different asserts). I think this is
>> cleanest but am open to criticism! I've covered everything I could think
>> of except for the badKeyUsage/badExtendedKeyUsage/badNetscapeCertType
>> cases, I have yet to figure out how to setup certs using them. Is there
>> any corner case I've missed?
>>
>> Comments are very appreciated!
>
> Some more whitespace might be nice (to separate the asserts from the
> code that sets up the preconditions and code that tests the object). We
> may also want to split off the separate responsibilities into separate
> classes. Still, I think it looks fantastic for now. Nicely done!

Separate responsibilities WRT what exactly?

The whitespaces definitely do help! =)

I've attached a new patch that loosens up the code a bit, I've padded newlines above (and below) the chunk of asserts. There are a few 
more modifications as follows.

1) The new patch also brings in the changeset that renames JarSigner to JarCertVerifier[1] so hopefully it won't throw reviewers off 
too much.
2) In the tests that run 1 entry than 3 entries, I've reset JarCertVerifier to a new instance when the three-entry vector is used. I 
think this may cause confusion later on because there would have been cases where the JarCertVerifier would have totalSignableEntries = 
4 instead of 3.
3) Lastly, I've added a new set of asserts using the following two methods:

     /**
      * Checks if the provided cert path has signed any of the jars associated
      * with the cert verifier.
      * @param certPath The cert path of the potential signer.
      * @return Whether or not the cert path represents one of the signers of
      * a jar associated with the verifier.
      */
     boolean hasJarSigner(CertPath certPath)

     /**
      * Calculate the number of signers all the jars have in total.
      *
      * Note this is not the number of common signers across all jars. It is
      * the number of common signers each jar has with respect to itself,
      * totalled together across the other jars.
      * @return The number of signers that have signed at least one jar entirely.
      */
     int numSigners()

These check that the right number of certs were added and clarifies that the right signer's cert path was stored in JarCertVerifier.

Cheers,
Danesh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jar-signer-tests-02.patch
Type: text/x-patch
Size: 30481 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120406/452e0cc9/jar-signer-tests-02.patch 

From ddadacha at redhat.com  Fri Apr  6 15:40:29 2012
From: ddadacha at redhat.com (Danesh Dadachanji)
Date: Fri, 06 Apr 2012 18:40:29 -0400
Subject: [RFC][icedtea-web] Unit tests for the new updates to JarSIgner
	(incomplete)
In-Reply-To: <4F7F66C2.8060506@redhat.com>
References: <4F7A1037.7060405@redhat.com> <4F7CDAF7.6090503@redhat.com>
	<4F7F66C2.8060506@redhat.com>
Message-ID: <4F7F70DD.7060004@redhat.com>

On 06/04/12 05:57 PM, Danesh Dadachanji wrote:
> Hi Omair,
>
> Thanks for the review!
>
> On 04/04/12 07:36 PM, Omair Majid wrote:
>> Hi Danesh,
>>
>> On 04/02/2012 04:46 PM, Danesh Dadachanji wrote:
>>> I've been working on updating JarSigner to be able to handle multiple
>>> signers properly. Currently, it mashes and saves all of the signers'
>>> properties (flags for expired/badly signed/not yet valid) as one. In
>>> other words, if one signer has expired, all signers are seen by
>>> IcedTea-Web as expired. If one has signing issues, then they all have
>>> signing issues. This is definitely not an ideal solution since we're
>>> telling users that verifiable applications are not verified.
>>>
>>> The attached patch contains a set of unit tests for the (former)
>>> verifyJar method. I'm going to avoid including the actual code for these
>>> changes just yet because the entire class isn't fully cleaned up. Here's
>>> a bit of background info on what I've changed though.
>>>
>>>
>>> * What verifyJar should be doing:
>>>
>>> My understanding of the idea behind verifyJar is that it does 2 somewhat
>>> separate tasks. First, given a jar, iterate over all of its entries. For
>>> every entry that can be signed, go through the list of signers and see
>>> if any have issues. If they do, setup the flags accordingly (issues
>>> could be expiry/bad key usage/not yet valid start date etc). Also, keep
>>> track of the number of entries each signer has signed, as well as the
>>> total number of possible signable entries. The second step is going
>>> through all of the signers after all the entries have been iterated over
>>> to see if there is a common signer that has signed them all. If there is
>>> any entry that is not signed but should be, or if there is one entry
>>> that does not share a common signer between all other entries, then this
>>> jar is considered UNSIGNED. If all entries (that should be signed) share
>>> a common signer, then the signer itself is checked. If the signer has
>>> signing issues, the jar is considered SIGNED_NOT_OKAY, if it has no
>>> signing issues, the jar is considered SIGNED_OK.
>>>
>>
>> This does make sense to me. Something that sort of jumps out at me is
>> that these two responsibilities are fairly distinct. It seems like it
>> might be worth it to split it into two distinct objects, each taking
>> care of one responsibility. That is, one objects determines if it should
>> be considered signed or unsigned, and another checks that (if signed)
>> the signing certificate is good.
>>
>
> Hmm interesting idea, it makes sense to separate the checking/setup of the signers and the checking of the jar. However, I would like
> to get back to you on this once I have wondered into the mess that is verifyJars(). I think there is definitely potential here to move
> bits into another class but I don't fully know what is needed by the rest of JarCertVerifier. Until I do, I would rather avoid
> refactoring this until it is needed.
>
>>> * Summary of my changes to verifyJar:
>>>
>>> I've split verifyJar into 2 methods, all the logic/implementations from
>>> line 265[1] and onwards is now in a method named verifyJarEntryCerts.
>>> Here's a quick snippet of its javadoc and method declaration:
>>>
>>> /**
>>> * Checks through all the jar entries for signers, storing all the
>>> common
>>> * ones in the certs hash map.
>>> * @param jarHasManifest Whether or not the associated jar has a
>>> manifest.
>>> * @param entries The list of entries in the associated jar.
>>> * @return If there is at least one signable entry that is not
>>> signed by a
>>> * common signer, return UNSIGNED. Otherwise every signable entry is
>>> * signed by at least one common signer. If the signer has no issues,
>>> * return SIGNED_OK. If there are any signing issues, return
>>> SIGNED_NOT_OK.
>>> * @throws Exception Will be thrown if there are issues with entries.
>>> */
>>> VerifyResult verifyJarEntryCerts(boolean jarHasManifest,
>>> Vector<JarEntry> entries) throws Exception
>>>
>>> The reason I've split this method up is so that JarSigner can be made
>>> unit testable. The method verifyJar takes in a jar name and
>>> creating/commiting one to upstream isn't suitable. Instead, I've created
>>> an extra helper method that takes in a list of jar entries and tests
>>> everything the original code tests. The new unit test class then hard
>>> codes these entries, along with their signers, to make this method
>>> testable.
>>
>> Good stuff!
>>
>
> Thanks!
>
>>> For the entries' signers, I've created a helper class that creates
>>> X509Certificate objects with specified domain names/start dates/validity
>>> periods. This code is essentially taken from
>>> sun.security.tools.KeyTool#doGenKeyPair (which calls
>>> KeyTool#doSelfCert), I've removed the bits that aren't needed
>>> (KeyStore/alias etc) and left the bare minimum that is needed to create
>>> an X509Certificate. I'm not 100% sure of the copyright header that is
>>> needed for this class so I used the same one provided by KeyTool from
>>> here [2] (with s/2011/2012). I would appreciate any insight as to if
>>> this is correct. =)
>>
>> IANAL. That said, you should note all the copyright owners. I believe
>> that would be Oracle (since they own the original code in KeyTool), and
>> Red Hat (since that's who owns the newer/modified code). Since both
>> Oracle and Red Hat have licensed the code under GPLv2+Classpath, it
>> should be okay to replace this version of the header with the one more
>> commonly used in icedtea-web (they do refer to the same license after all).
>>
>>> The unit tests themselves are pretty self-explanatory, to save on
>>> space/repetition, I've kept testing 1 entry and then 3 entries with the
>>> same scenario under one method (with different asserts). I think this is
>>> cleanest but am open to criticism! I've covered everything I could think
>>> of except for the badKeyUsage/badExtendedKeyUsage/badNetscapeCertType
>>> cases, I have yet to figure out how to setup certs using them. Is there
>>> any corner case I've missed?
>>>
>>> Comments are very appreciated!
>>
>> Some more whitespace might be nice (to separate the asserts from the
>> code that sets up the preconditions and code that tests the object). We
>> may also want to split off the separate responsibilities into separate
>> classes. Still, I think it looks fantastic for now. Nicely done!
>
> Separate responsibilities WRT what exactly?
>
> The whitespaces definitely do help! =)
>
> I've attached a new patch that loosens up the code a bit, I've padded newlines above (and below) the chunk of asserts. There are a few
> more modifications as follows.
>
> 1) The new patch also brings in the changeset that renames JarSigner to JarCertVerifier[1] so hopefully it won't throw reviewers off
> too much.
> 2) In the tests that run 1 entry than 3 entries, I've reset JarCertVerifier to a new instance when the three-entry vector is used. I
> think this may cause confusion later on because there would have been cases where the JarCertVerifier would have totalSignableEntries =
> 4 instead of 3.
> 3) Lastly, I've added a new set of asserts using the following two methods:
>
> /**
> * Checks if the provided cert path has signed any of the jars associated
> * with the cert verifier.
> * @param certPath The cert path of the potential signer.
> * @return Whether or not the cert path represents one of the signers of
> * a jar associated with the verifier.
> */
> boolean hasJarSigner(CertPath certPath)
>
> /**
> * Calculate the number of signers all the jars have in total.
> *
> * Note this is not the number of common signers across all jars. It is
> * the number of common signers each jar has with respect to itself,
> * totalled together across the other jars.
> * @return The number of signers that have signed at least one jar entirely.
> */
> int numSigners()
>
> These check that the right number of certs were added and clarifies that the right signer's cert path was stored in JarCertVerifier.
>

Knew I forgot something..Fridays :/

[1] http://icedtea.classpath.org/hg/icedtea-web/rev/cde6d59a2901

> Cheers,
> Danesh


From bugzilla-daemon at icedtea.classpath.org  Sat Apr  7 02:47:29 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Sat, 07 Apr 2012 09:47:29 +0000
Subject: [Bug 915] New: OpenJDK crashes with no aparent reason
Message-ID: <bug-915-30@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=915

             Bug #: 915
           Summary: OpenJDK crashes with no aparent reason
    Classification: Unclassified
           Product: IcedTea
           Version: unspecified
          Platform: x86
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: IcedTea
        AssignedTo: unassigned at icedtea.classpath.org
        ReportedBy: mnbsantos at gmail.com


Here's the error log


?#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xb7f7f34e, pid=1601, tid=2127809424
#
# JRE version: 6.0_22-b22
# Java VM: OpenJDK Client VM (20.0-b11 mixed mode linux-x86 )
# Derivative: IcedTea6 1.10.6
# Distribution: CentOS release 5.7 (Final), package rhel-1.25.1.10.6.el5_8-i386
# Problematic frame:
# C  [libz.so.1+0x834e]  inflateEnd+0x2e
#
# If you would like to submit a bug report, please include
# instructions how to reproduce the bug and visit:
#   http://icedtea.classpath.org/bugzilla
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---------------  T H R E A D  ---------------

Current thread (0x087e0400):  JavaThread "Finalizer" daemon [_thread_in_native,
id=1605, stack(0x7ecec000,0x7ed3d000)]

siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR),
si_addr=0x7a20d03c

Registers:
EAX=0x7a20d008, EBX=0xb7346d34, ECX=0xb7f7f070, EDX=0x087e0520
ESP=0x7ed3bb40, EBP=0x7ed3bb58, ESI=0x7dfab7c0, EDI=0x087e0400
EIP=0xb7f7f34e, EFLAGS=0x00010282, CR2=0x7a20d03c

Top of Stack: (sp=0x7ed3bb40)
0x7ed3bb40:   00000000 7a20a008 00000000 b7346d34
0x7ed3bb50:   7dfab800 7dfab7c0 7ed3bb78 b7342655
0x7ed3bb60:   7dfab7c0 00000000 7ed3bb98 00000000
0x7ed3bb70:   7ed3bb98 087e0400 7ed3bba8 b57e909c
0x7ed3bb80:   087e0520 7ed3bb98 7dfab7c0 00000000
0x7ed3bb90:   95a08ca8 00000009 b1466c30 b773e915
0x7ed3bba0:   b13c97b8 b1802820 7ed3bc38 b57d9110
0x7ed3bbb0:   7dfab7c0 00000000 00000000 7ed3bbb4 

Instructions: (pc=0xb7f7f34e)
0xb7f7f32e:   b8 fe ff ff ff 83 c4 14 5e 5d c3 8d b4 26 00 00
0xb7f7f33e:   00 00 8b 46 1c 85 c0 74 e7 8b 4e 24 85 c9 74 e0
0xb7f7f34e:   8b 50 34 85 d2 74 12 89 54 24 04 8b 46 28 89 04
0xb7f7f35e:   24 ff d1 8b 46 1c 8b 4e 24 89 44 24 04 8b 46 28 

Register to memory mapping:

EAX=0x7a20d008 is an unknown value
EBX=0xb7346d34: <offset 0x6d34> in
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/libzip.so at 0xb7340000
ECX=0xb7f7f070: zcfree+0 in /usr/lib/libz.so.1 at 0xb7f77000
EDX=0x087e0520 is an unknown value
ESP=0x7ed3bb40 is pointing into the stack for thread: 0x087e0400
EBP=0x7ed3bb58 is pointing into the stack for thread: 0x087e0400
ESI=0x7dfab7c0 is an unknown value
EDI=0x087e0400 is a thread


Stack: [0x7ecec000,0x7ed3d000],  sp=0x7ed3bb40,  free space=318k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libz.so.1+0x834e]  inflateEnd+0x2e
C  [libzip.so+0x2655]  Java_java_util_zip_Inflater_end+0x25
J  java.util.zip.Inflater.end(J)V
J  java.util.zip.Inflater.end()V
V  [libjvm.so+0x22b759]  AsyncGetCallTrace+0x77fb9
V  [libjvm.so+0x3586c9]  numa_error+0x229
V  [libjvm.so+0x22a73f]  AsyncGetCallTrace+0x76f9f
V  [libjvm.so+0x236edd]  JNI_CreateJavaVM+0x82d
V  [libjvm.so+0x256c90]  JNI_CreateJavaVM+0x205e0
C  [libjava.so+0xbf0e]  Java_java_lang_ref_Finalizer_invokeFinalizeMethod+0x6e
J  java.lang.ref.Finalizer.invokeFinalizeMethod(Ljava/lang/Object;)V
J  java.lang.ref.Finalizer.runFinalizer()V
V  [libjvm.so+0x22b759]  AsyncGetCallTrace+0x77fb9
V  [libjvm.so+0x3586c9]  numa_error+0x229
V  [libjvm.so+0x22a73f]  AsyncGetCallTrace+0x76f9f
V  [libjvm.so+0x22a854]  AsyncGetCallTrace+0x770b4
V  [libjvm.so+0x22ad08]  AsyncGetCallTrace+0x77568
V  [libjvm.so+0x284928]  JVM_DisableCompiler+0x1248
V  [libjvm.so+0x4064dc]  JVM_handle_linux_signal+0xa52cc
V  [libjvm.so+0x4065bc]  JVM_handle_linux_signal+0xa53ac
V  [libjvm.so+0x35ed88]  fork1+0x5c58
C  [libpthread.so.0+0x5832]  start_thread+0xe2

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J  java.util.zip.Inflater.end(J)V
J  java.util.zip.Inflater.end()V
J  java.util.zip.Inflater.finalize()V
v  ~StubRoutines::call_stub
J  java.lang.ref.Finalizer.invokeFinalizeMethod(Ljava/lang/Object;)V
J  java.lang.ref.Finalizer.runFinalizer()V
J  java.lang.ref.Finalizer$FinalizerThread.run()V
v  ~StubRoutines::call_stub

---------------  P R O C E S S  ---------------

Java Threads: ( => current thread )
  0x089f8800 JavaThread "Connection #169 write thread" [_thread_blocked,
id=26050, stack(0x792af000,0x79300000)]
  0x0daa4c00 JavaThread "Connection #169 read thread" [_thread_in_native,
id=26049, stack(0x7ca0d000,0x7ca5e000)]
  0x089d0000 JavaThread "Connection #167 write thread" [_thread_blocked,
id=25966, stack(0x7a2af000,0x7a300000)]
  0x087c0000 JavaThread "Connection #167 read thread" [_thread_in_native,
id=25965, stack(0x7e5d6000,0x7e627000)]
  0x088c4800 JavaThread "Connection #160 write thread" [_thread_blocked,
id=24365, stack(0x7e25e000,0x7e2af000)]
  0x087c5400 JavaThread "Connection #160 read thread" [_thread_in_native,
id=24364, stack(0x7ca5e000,0x7caaf000)]
  0x09800c00 JavaThread "Connection #98 write thread" [_thread_blocked,
id=18169, stack(0x7e20d000,0x7e25e000)]
  0x0882c800 JavaThread "Connection #98 read thread" [_thread_in_native,
id=18168, stack(0x7e2af000,0x7e300000)]
  0x7d1fa800 JavaThread "Thread-102" [_thread_blocked, id=3915,
stack(0x7925e000,0x792af000)]
  0x79121400 JavaThread "Thread-101" [_thread_blocked, id=3914,
stack(0x7e678000,0x7e6c9000)]
  0x7e10f800 JavaThread "Thread-100" [_thread_blocked, id=3913,
stack(0x7e6c9000,0x7e71a000)]
  0x0cad5000 JavaThread "File IO Thread" [_thread_blocked, id=1628,
stack(0x7e7f8000,0x7e849000)]
  0x08be5800 JavaThread "Thread-6" [_thread_blocked, id=1619,
stack(0x7e71a000,0x7e76b000)]
  0x08917c00 JavaThread "Thread-4" [_thread_blocked, id=1616,
stack(0x7e849000,0x7e89a000)]
  0x08913000 JavaThread "Listen thread" [_thread_in_native, id=1615,
stack(0x7e89a000,0x7e8eb000)]
  0x088ea800 JavaThread "Thread-3" daemon [_thread_in_native, id=1614,
stack(0x7e95b000,0x7e9ac000)]
  0x08789000 JavaThread "DestroyJavaVM" [_thread_blocked, id=1602,
stack(0xb73b2000,0xb7403000)]
  0x08900000 JavaThread "Server thread" [_thread_blocked, id=1613,
stack(0x7e90a000,0x7e95b000)]
  0x088f1800 JavaThread "Thread-1" daemon [_thread_blocked, id=1610,
stack(0x7e9ac000,0x7e9fd000)]
  0x087f8800 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=1608,
stack(0x7eb87000,0x7ebd8000)]
  0x087f5000 JavaThread "C1 CompilerThread0" daemon [_thread_blocked, id=1607,
stack(0x7ebd8000,0x7ec59000)]
  0x087f3c00 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=1606,
stack(0x7ec59000,0x7ecaa000)]
=>0x087e0400 JavaThread "Finalizer" daemon [_thread_in_native, id=1605,
stack(0x7ecec000,0x7ed3d000)]
  0x087dec00 JavaThread "Reference Handler" daemon [_thread_blocked, id=1604,
stack(0x7ed3d000,0x7ed8e000)]

Other Threads:
  0x087dac00 VMThread [stack: 0x7ed8e000,0x7ee0f000] [id=1603]
  0x087fa800 WatcherThread [stack: 0x7eb06000,0x7eb87000] [id=1609]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap
 def new generation   total 245760K, used 13931K [0x7f2c0000, 0x8fd60000,
0x8fd60000)
  eden space 218496K,   1% used [0x7f2c0000, 0x7f6d47c0, 0x8c820000)
  from space 27264K,  35% used [0x8e2c0000, 0x8ec46520, 0x8fd60000)
  to   space 27264K,   0% used [0x8c820000, 0x8c820000, 0x8e2c0000)
 tenured generation   total 546176K, used 508823K [0x8fd60000, 0xb12c0000,
0xb12c0000)
   the space 546176K,  93% used [0x8fd60000, 0xaee45dc0, 0xaee45e00,
0xb12c0000)
 compacting perm gen  total 16384K, used 16276K [0xb12c0000, 0xb22c0000,
0xb52c0000)
   the space 16384K,  99% used [0xb12c0000, 0xb22a5180, 0xb22a5200, 0xb22c0000)
No shared spaces configured.

Code Cache  [0xb5340000, 0xb5978000, 0xb7340000)
 total_blobs=3542 nmethods=3327 adapters=149 free_code_cache=27068352
largest_free_block=5888

Dynamic libraries:
08048000-08051000 r-xp 00000000 08:04 28412844                          
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/bin/java
08051000-08052000 rw-p 00008000 08:04 28412844                          
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/bin/java
08783000-0dae9000 rw-p 08783000 00:00 0                                  [heap]
77100000-771fb000 rw-p 77100000 00:00 0 
771fb000-77200000 ---p 771fb000 00:00 0 
77200000-77300000 rw-p 77200000 00:00 0 
77300000-773fb000 rw-p 77300000 00:00 0 
773fb000-77400000 ---p 773fb000 00:00 0 
77400000-77500000 rw-p 77400000 00:00 0 
77500000-775fb000 rw-p 77500000 00:00 0 
775fb000-77600000 ---p 775fb000 00:00 0 
77600000-77700000 rw-p 77600000 00:00 0 
77700000-777fb000 rw-p 77700000 00:00 0 
777fb000-77800000 ---p 777fb000 00:00 0 
77800000-77900000 rw-p 77800000 00:00 0 
77900000-779fb000 rw-p 77900000 00:00 0 
779fb000-77a00000 ---p 779fb000 00:00 0 
77a00000-77b00000 rw-p 77a00000 00:00 0 
77b00000-77bfb000 rw-p 77b00000 00:00 0 
77bfb000-77c00000 ---p 77bfb000 00:00 0 
77c00000-77d00000 rw-p 77c00000 00:00 0 
77d00000-77efb000 rw-p 77d00000 00:00 0 
77efb000-77f00000 ---p 77efb000 00:00 0 
77f00000-77ff4000 rw-p 77f00000 00:00 0 
77ff4000-78000000 ---p 77ff4000 00:00 0 
78000000-780ff000 rw-p 78000000 00:00 0 
780ff000-78100000 ---p 780ff000 00:00 0 
78100000-782fb000 rw-p 78100000 00:00 0 
782fb000-78300000 ---p 782fb000 00:00 0 
78300000-783fb000 rw-p 78300000 00:00 0 
783fb000-78400000 ---p 783fb000 00:00 0 
78400000-78500000 rw-p 78400000 00:00 0 
78500000-785fb000 rw-p 78500000 00:00 0 
785fb000-78600000 ---p 785fb000 00:00 0 
78600000-78700000 rw-p 78600000 00:00 0 
78700000-78800000 rw-p 78700000 00:00 0 
78900000-789fe000 rw-p 78900000 00:00 0 
789fe000-78a00000 ---p 789fe000 00:00 0 
78b00000-78bee000 rw-p 78b00000 00:00 0 
78bee000-78c00000 ---p 78bee000 00:00 0 
78caf000-78cb2000 ---p 78caf000 00:00 0 
78cb2000-78e8b000 rw-p 78cb2000 00:00 0 
78e8b000-78f00000 ---p 78e8b000 00:00 0 
78f00000-78ff6000 rw-p 78f00000 00:00 0 
78ff6000-79000000 ---p 78ff6000 00:00 0 
79000000-790f0000 rw-p 79000000 00:00 0 
790f0000-79100000 ---p 790f0000 00:00 0 
79100000-79200000 rw-p 79100000 00:00 0 
7920d000-79210000 ---p 7920d000 00:00 0 
79210000-7925e000 rw-p 79210000 00:00 0 
7925e000-79261000 ---p 7925e000 00:00 0 
79261000-792af000 rw-p 79261000 00:00 0 
792af000-792b2000 ---p 792af000 00:00 0 
792b2000-794fb000 rw-p 792b2000 00:00 0 
794fb000-79500000 ---p 794fb000 00:00 0 
79500000-796fb000 rw-p 79500000 00:00 0 
796fb000-79700000 ---p 796fb000 00:00 0 
79700000-798fb000 rw-p 79700000 00:00 0 
798fb000-79900000 ---p 798fb000 00:00 0 
79900000-79afb000 rw-p 79900000 00:00 0 
79afb000-79b00000 ---p 79afb000 00:00 0 
79b00000-79cfb000 rw-p 79b00000 00:00 0 
79cfb000-79d00000 ---p 79cfb000 00:00 0 
79d00000-79dfb000 rw-p 79d00000 00:00 0 
79dfb000-79e00000 ---p 79dfb000 00:00 0 
79e00000-79f00000 rw-p 79e00000 00:00 0 
79f00000-7a100000 rw-p 79f00000 00:00 0 
7a100000-7a200000 rw-p 7a100000 00:00 0 
7a210000-7a25e000 rw-p 7a210000 00:00 0 
7a25e000-7a261000 ---p 7a25e000 00:00 0 
7a261000-7a2af000 rw-p 7a261000 00:00 0 
7a2af000-7a2b2000 ---p 7a2af000 00:00 0 
7a2b2000-7a4fb000 rw-p 7a2b2000 00:00 0 
7a4fb000-7a500000 ---p 7a4fb000 00:00 0 
7a500000-7a6fb000 rw-p 7a500000 00:00 0 
7a6fb000-7a700000 ---p 7a6fb000 00:00 0 
7a700000-7a8fb000 rw-p 7a700000 00:00 0 
7a8fb000-7a900000 ---p 7a8fb000 00:00 0 
7a900000-7aafb000 rw-p 7a900000 00:00 0 
7aafb000-7ab00000 ---p 7aafb000 00:00 0 
7ab00000-7acfb000 rw-p 7ab00000 00:00 0 
7acfb000-7ad00000 ---p 7acfb000 00:00 0 
7ad00000-7aefb000 rw-p 7ad00000 00:00 0 
7aefb000-7af00000 ---p 7aefb000 00:00 0 
7af00000-7b0fb000 rw-p 7af00000 00:00 0 
7b0fb000-7b100000 ---p 7b0fb000 00:00 0 
7b100000-7b2fb000 rw-p 7b100000 00:00 0 
7b2fb000-7b300000 ---p 7b2fb000 00:00 0 
7b300000-7b4fb000 rw-p 7b300000 00:00 0 
7b4fb000-7b500000 ---p 7b4fb000 00:00 0 
7b500000-7b6fb000 rw-p 7b500000 00:00 0 
7b6fb000-7b700000 ---p 7b6fb000 00:00 0 
7b700000-7b8fb000 rw-p 7b700000 00:00 0 
7b8fb000-7b900000 ---p 7b8fb000 00:00 0 
7b900000-7bafb000 rw-p 7b900000 00:00 0 
7bafb000-7bb00000 ---p 7bafb000 00:00 0 
7bb00000-7bcfd000 rw-p 7bb00000 00:00 0 
7bcfd000-7bd00000 ---p 7bcfd000 00:00 0 
7bd00000-7befb000 rw-p 7bd00000 00:00 0 
7befb000-7bf00000 ---p 7befb000 00:00 0 
7bf00000-7c0fb000 rw-p 7bf00000 00:00 0 
7c0fb000-7c100000 ---p 7c0fb000 00:00 0 
7c100000-7c2fb000 rw-p 7c100000 00:00 0 
7c2fb000-7c300000 ---p 7c2fb000 00:00 0 
7c300000-7c4fb000 rw-p 7c300000 00:00 0 
7c4fb000-7c500000 ---p 7c4fb000 00:00 0 
7c500000-7c6fb000 rw-p 7c500000 00:00 0 
7c6fb000-7c700000 ---p 7c6fb000 00:00 0 
7c700000-7c8fb000 rw-p 7c700000 00:00 0 
7c8fb000-7c900000 ---p 7c8fb000 00:00 0 
7c900000-7c9fb000 rw-p 7c900000 00:00 0 
7c9fb000-7ca00000 ---p 7c9fb000 00:00 0 
7ca01000-7ca0d000 rw-p 7ca01000 00:00 0 
7ca0d000-7ca10000 ---p 7ca0d000 00:00 0 
7ca10000-7ca5e000 rw-p 7ca10000 00:00 0 
7ca5e000-7ca61000 ---p 7ca5e000 00:00 0 
7ca61000-7caaf000 rw-p 7ca61000 00:00 0 
7caaf000-7cab2000 ---p 7caaf000 00:00 0 
7cab2000-7cbfb000 rw-p 7cab2000 00:00 0 
7cbfb000-7cc00000 ---p 7cbfb000 00:00 0 
7cc00000-7cd00000 rw-p 7cc00000 00:00 0 
7cd00000-7cdfb000 rw-p 7cd00000 00:00 0 
7cdfb000-7ce00000 ---p 7cdfb000 00:00 0 
7ce00000-7cf00000 rw-p 7ce00000 00:00 0 
7cf00000-7d000000 rw-p 7cf00000 00:00 0 
7d001000-7d00d000 rw-p 7d001000 00:00 0 
7d00d000-7d010000 ---p 7d00d000 00:00 0 
7d010000-7d05e000 rw-p 7d010000 00:00 0 
7d05e000-7d061000 ---p 7d05e000 00:00 0 
7d061000-7d0af000 rw-p 7d061000 00:00 0 
7d0af000-7d0b2000 ---p 7d0af000 00:00 0 
7d0b2000-7d1fb000 rw-p 7d0b2000 00:00 0 
7d1fb000-7d200000 ---p 7d1fb000 00:00 0 
7d200000-7d300000 rw-p 7d200000 00:00 0 
7d300000-7d3fb000 rw-p 7d300000 00:00 0 
7d3fb000-7d400000 ---p 7d3fb000 00:00 0 
7d400000-7d500000 rw-p 7d400000 00:00 0 
7d500000-7d5fb000 rw-p 7d500000 00:00 0 
7d5fb000-7d600000 ---p 7d5fb000 00:00 0 
7d600000-7d700000 rw-p 7d600000 00:00 0 
7d700000-7d7fb000 rw-p 7d700000 00:00 0 
7d7fb000-7d800000 ---p 7d7fb000 00:00 0 
7d800000-7d900000 rw-p 7d800000 00:00 0 
7d900000-7d9fb000 rw-p 7d900000 00:00 0 
7d9fb000-7da00000 ---p 7d9fb000 00:00 0 
7da00000-7db00000 rw-p 7da00000 00:00 0 
7db00000-7dbfb000 rw-p 7db00000 00:00 0 
7dbfb000-7dc00000 ---p 7dbfb000 00:00 0 
7dc00000-7dd00000 rw-p 7dc00000 00:00 0 
7dd00000-7ddfb000 rw-p 7dd00000 00:00 0 
7ddfb000-7de00000 ---p 7ddfb000 00:00 0 
7de00000-7df00000 rw-p 7de00000 00:00 0 
7df00000-7dff9000 rw-p 7df00000 00:00 0 
7dff9000-7e000000 ---p 7dff9000 00:00 0 
7e000000-7e100000 rw-p 7e000000 00:00 0 
7e100000-7e1ff000 rw-p 7e100000 00:00 0 
7e1ff000-7e200000 ---p 7e1ff000 00:00 0 
7e201000-7e20d000 rw-p 7e201000 00:00 0 
7e20d000-7e210000 ---p 7e20d000 00:00 0 
7e210000-7e25e000 rw-p 7e210000 00:00 0 
7e25e000-7e261000 ---p 7e25e000 00:00 0 
7e261000-7e2af000 rw-p 7e261000 00:00 0 
7e2af000-7e2b2000 ---p 7e2af000 00:00 0 
7e2b2000-7e3fe000 rw-p 7e2b2000 00:00 0 
7e3fe000-7e400000 ---p 7e3fe000 00:00 0 
7e401000-7e41c000 rw-p 7e401000 00:00 0 
7e434000-7e441000 r--s 000ae000 08:04 27140741                          
/root/plugins/WorldEdit.jar
7e441000-7e444000 ---p 7e441000 00:00 0 
7e444000-7e492000 rw-p 7e444000 00:00 0 
7e492000-7e495000 ---p 7e492000 00:00 0 
7e495000-7e4e3000 rw-p 7e495000 00:00 0 
7e4e3000-7e4e6000 ---p 7e4e3000 00:00 0 
7e4e6000-7e534000 rw-p 7e4e6000 00:00 0 
7e534000-7e537000 ---p 7e534000 00:00 0 
7e537000-7e585000 rw-p 7e537000 00:00 0 
7e585000-7e588000 ---p 7e585000 00:00 0 
7e588000-7e5d6000 rw-p 7e588000 00:00 0 
7e5d6000-7e5d9000 ---p 7e5d6000 00:00 0 
7e5d9000-7e627000 rw-p 7e5d9000 00:00 0 
7e627000-7e62a000 ---p 7e627000 00:00 0 
7e62a000-7e678000 rw-p 7e62a000 00:00 0 
7e678000-7e67b000 ---p 7e678000 00:00 0 
7e67b000-7e6c9000 rw-p 7e67b000 00:00 0 
7e6c9000-7e6cc000 ---p 7e6c9000 00:00 0 
7e6cc000-7e71a000 rw-p 7e6cc000 00:00 0 
7e71a000-7e71d000 ---p 7e71a000 00:00 0 
7e71d000-7e76b000 rw-p 7e71d000 00:00 0 
7e76b000-7e76e000 ---p 7e76b000 00:00 0 
7e76e000-7e7bc000 rw-p 7e76e000 00:00 0 
7e7bc000-7e7be000 r--s 0000f000 08:04 27140677                          
/root/plugins/NoLagg.jar
7e7be000-7e7c0000 r--s 00002000 08:04 27140668                          
/root/plugins/EssentialsSpawn.jar
7e7c0000-7e7c2000 r--s 0000d000 08:04 27140679                          
/root/plugins/NoLaggExamine.jar
7e7c2000-7e7c3000 r--s 00007000 08:04 27140703                          
/root/plugins/NoLaggTNT.jar
7e7c3000-7e7c5000 r--s 00003000 08:04 27140695                          
/root/plugins/NoLaggItemBuffer.jar
7e7c5000-7e7c9000 r--s 00042000 08:04 27140669                          
/root/plugins/Factions.jar
7e7c9000-7e7d3000 r--s 00099000 08:04 27140657                          
/root/plugins/Essentials.jar
7e7d3000-7e7d4000 r--s 00003000 08:04 22020097                          
/root/plugins/AntiCreeper.jar
7e7d4000-7e7d5000 r--s 0000b000 08:04 27140678                          
/root/plugins/NoLaggChunks.jar
7e7d5000-7e7d6000 r--s 00005000 08:04 27140696                          
/root/plugins/NoLaggItemStacker.jar
7e7d6000-7e7d7000 r--s 0000d000 08:04 27140537                          
/root/plugins/Lockette.jar
7e7d7000-7e7da000 r--s 00021000 08:04 27140671                          
/root/plugins/BKCommonLib.jar
7e7da000-7e7ea000 r-xp 00000000 08:04 26076644                          
/lib/libresolv-2.5.so
7e7ea000-7e7eb000 r--p 0000f000 08:04 26076644                          
/lib/libresolv-2.5.so
7e7eb000-7e7ec000 rw-p 00010000 08:04 26076644                          
/lib/libresolv-2.5.so
7e7ec000-7e7ee000 rw-p 7e7ec000 00:00 0 
7e7ee000-7e7f2000 r-xp 00000000 08:04 26076635                          
/lib/libnss_dns-2.5.so
7e7f2000-7e7f3000 r--p 00003000 08:04 26076635                          
/lib/libnss_dns-2.5.so
7e7f3000-7e7f4000 rw-p 00004000 08:04 26076635                          
/lib/libnss_dns-2.5.so
7e7f5000-7e7f8000 r--s 00018000 08:04 27140617                          
/root/plugins/AuthMe-2.6.3.b3.jar
7e7f8000-7e7fb000 ---p 7e7f8000 00:00 0 
7e7fb000-7e849000 rw-p 7e7fb000 00:00 0 
7e849000-7e84c000 ---p 7e849000 00:00 0 
7e84c000-7e89a000 rw-p 7e84c000 00:00 0 
7e89a000-7e89d000 ---p 7e89a000 00:00 0 
7e89d000-7e8eb000 rw-p 7e89d000 00:00 0 
7e8eb000-7e8ee000 r--s 00076000 08:04 28437304                          
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/ext/localedata.jar
7e8ee000-7e8f5000 r-xp 00000000 08:04 28468078                          
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/libnio.so
7e8f5000-7e8f6000 rw-p 00006000 08:04 28468078                          
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/libnio.so
7e8f6000-7e909000 r-xp 00000000 08:04 28468077                          
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/libnet.so
7e909000-7e90a000 rw-p 00013000 08:04 28468077                          
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/libnet.so
7e90a000-7e90d000 ---p 7e90a000 00:00 0 
7e90d000-7e95b000 rw-p 7e90d000 00:00 0 
7e95b000-7e95e000 ---p 7e95b000 00:00 0 
7e95e000-7e9ac000 rw-p 7e95e000 00:00 0 
7e9ac000-7e9af000 ---p 7e9ac000 00:00 0 
7e9af000-7e9fd000 rw-p 7e9af000 00:00 0 
7e9fd000-7ea7d000 r--s 00a17000 08:04 26127280                          
/root/craftbukkit.jar
7ea7d000-7ea86000 r--s 00060000 08:04 28437303                          
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/ext/gnome-java-bridge.jar
7ea88000-7eab5000 rw-p 7ea88000 00:00 0 
7eab5000-7eab8000 ---p 7eab5000 00:00 0 
7eab8000-7eb06000 rw-p 7eab8000 00:00 0 
7eb06000-7eb07000 ---p 7eb06000 00:00 0 
7eb07000-7eb87000 rw-p 7eb07000 00:00 0 
7eb87000-7eb8a000 ---p 7eb87000 00:00 0 
7eb8a000-7ebd8000 rw-p 7eb8a000 00:00 0 
7ebd8000-7ebdb000 ---p 7ebd8000 00:00 0 
7ebdb000-7ec59000 rw-p 7ebdb000 00:00 0 
7ec59000-7ec5c000 ---p 7ec59000 00:00 0 
7ec5c000-7ecaa000 rw-p 7ec5c000 00:00 0 
7ecaa000-7ecb1000 r--s 00000000 08:04 24217177                          
/usr/lib/gconv/gconv-modules.cache
7ecb1000-7ecec000 r--p 00000000 08:04 24193209                          
/usr/lib/locale/en_US.utf8/LC_CTYPE
7ecec000-7ecef000 ---p 7ecec000 00:00 0 
7ecef000-7ed3d000 rw-p 7ecef000 00:00 0 
7ed3d000-7ed40000 ---p 7ed3d000 00:00 0 
7ed40000-7ed8e000 rw-p 7ed40000 00:00 0 
7ed8e000-7ed8f000 ---p 7ed8e000 00:00 0 
7ed8f000-7ee44000 rw-p 7ed8f000 00:00 0 
7ee44000-7efe3000 r--s 01978000 08:04 28420220                          
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/rt.jar
7efe3000-7efec000 rw-p 7efe3000 00:00 0 
7efec000-7efed000 ---p 7efec000 00:00 0 
7efed000-7f004000 rw-p 7efed000 00:00 0 
7f004000-7f2a7000 rw-p 7f004000 00:00 0 
7f2a7000-7f2a9000 ---p 7f2a7000 00:00 0 
7f2a9000-7f2bf000 rw-p 7f2a9000 00:00 0 
7f2bf000-b22c0000 rw-p 7f2bf000 00:00 0 
b22c0000-b2500000 ---p b22c0000 00:00 0 
b2500000-b52c0000 rw-p b2500000 00:00 0 
b52c0000-b52d9000 rw-p b52c0000 00:00 0 
b52d9000-b5340000 rw-p b52d9000 00:00 0 
b5340000-b5978000 rwxp b5340000 00:00 0 
b5978000-b7340000 rw-p b5978000 00:00 0 
b7340000-b7346000 r-xp 00000000 08:04 28468123                          
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/libzip.so
b7346000-b7347000 rw-p 00005000 08:04 28468123                          
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/libzip.so
b7347000-b734f000 rw-s 00000000 08:04 2917867                           
/tmp/hsperfdata_root/1601
b734f000-b7359000 r-xp 00000000 08:04 26076722                          
/lib/libnss_files-2.5.so
b7359000-b735a000 r--p 00009000 08:04 26076722                          
/lib/libnss_files-2.5.so
b735a000-b735b000 rw-p 0000a000 08:04 26076722                          
/lib/libnss_files-2.5.so
b735b000-b735f000 r--s 0003a000 08:04 28420210                          
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/jsse.jar
b735f000-b7374000 r-xp 00000000 08:04 26076662                          
/lib/libnsl-2.5.so
b7374000-b7375000 r--p 00014000 08:04 26076662                          
/lib/libnsl-2.5.so
b7375000-b7376000 rw-p 00015000 08:04 26076662                          
/lib/libnsl-2.5.so
b7376000-b7378000 rw-p b7376000 00:00 0 
b7378000-b739a000 r-xp 00000000 08:04 28468064                          
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/libjava.so
b739a000-b739c000 rw-p 00022000 08:04 28468064                          
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/libjava.so
b739c000-b73a8000 r-xp 00000000 08:04 28468122                          
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/libverify.so
b73a8000-b73a9000 rw-p 0000b000 08:04 28468122                          
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/libverify.so
b73a9000-b73b0000 r-xp 00000000 08:04 26076713                          
/lib/librt-2.5.so
b73b0000-b73b1000 r--p 00007000 08:04 26076713                          
/lib/librt-2.5.so
b73b1000-b73b2000 rw-p 00008000 08:04 26076713                          
/lib/librt-2.5.so
b73b2000-b73b5000 ---p b73b2000 00:00 0 
b73b5000-b7403000 rw-p b73b5000 00:00 0 
b7403000-b740e000 r-xp 00000000 08:04 26076613                          
/lib/libgcc_s-4.1.2-20080825.so.1
b740e000-b740f000 rw-p 0000a000 08:04 26076613                          
/lib/libgcc_s-4.1.2-20080825.so.1
b740f000-b7436000 r-xp 00000000 08:04 26076636                          
/lib/libm-2.5.so
b7436000-b7437000 r--p 00026000 08:04 26076636                          
/lib/libm-2.5.so
b7437000-b7438000 rw-p 00027000 08:04 26076636                          
/lib/libm-2.5.so
b7438000-b7516000 r-xp 00000000 08:04 24166444                          
/usr/lib/libstdc++.so.6.0.8
b7516000-b7519000 r--p 000dd000 08:04 24166444                          
/usr/lib/libstdc++.so.6.0.8
b7519000-b751b000 rw-p 000e0000 08:04 24166444                          
/usr/lib/libstdc++.so.6.0.8
b751b000-b7521000 rw-p b751b000 00:00 0 
b7521000-b79bf000 r-xp 00000000 08:04 28467839                          
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/client/libjvm.so
b79bf000-b79e3000 rw-p 0049d000 08:04 28467839                          
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/client/libjvm.so
b79e3000-b7dfc000 rw-p b79e3000 00:00 0 
b7dfc000-b7f4f000 r-xp 00000000 08:04 26076691                          
/lib/libc-2.5.so
b7f4f000-b7f51000 r--p 00153000 08:04 26076691                          
/lib/libc-2.5.so
b7f51000-b7f52000 rw-p 00155000 08:04 26076691                          
/lib/libc-2.5.so
b7f52000-b7f55000 rw-p b7f52000 00:00 0 
b7f55000-b7f58000 r-xp 00000000 08:04 26076720                          
/lib/libdl-2.5.so
b7f58000-b7f59000 r--p 00002000 08:04 26076720                          
/lib/libdl-2.5.so
b7f59000-b7f5a000 rw-p 00003000 08:04 26076720                          
/lib/libdl-2.5.so
b7f5a000-b7f5d000 r-xp 00000000 08:04 28491781                          
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/jli/libjli.so
b7f5d000-b7f5e000 rw-p 00003000 08:04 28491781                          
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/jli/libjli.so
b7f5e000-b7f73000 r-xp 00000000 08:04 26076614                          
/lib/libpthread-2.5.so
b7f73000-b7f74000 r--p 00015000 08:04 26076614                          
/lib/libpthread-2.5.so
b7f74000-b7f75000 rw-p 00016000 08:04 26076614                          
/lib/libpthread-2.5.so
b7f75000-b7f77000 rw-p b7f75000 00:00 0 
b7f77000-b7f89000 r-xp 00000000 08:04 24167661                          
/usr/lib/libz.so.1.2.3
b7f89000-b7f8a000 rw-p 00011000 08:04 24167661                          
/usr/lib/libz.so.1.2.3
b7f8a000-b7f8b000 r--s 00004000 08:04 27140697                          
/root/plugins/NoLaggLighting.jar
b7f8b000-b7f8c000 r--s 00006000 08:04 27140702                          
/root/plugins/NoLaggMonitor.jar
b7f8c000-b7f8d000 r--p b7f8c000 00:00 0 
b7f8d000-b7f8e000 r--p b7f8d000 00:00 0 
b7f8e000-b7f8f000 rw-p b7f8e000 00:00 0 
b7f8f000-b7faa000 r-xp 00000000 08:04 26076690                          
/lib/ld-2.5.so
b7faa000-b7fab000 r--p 0001a000 08:04 26076690                          
/lib/ld-2.5.so
b7fab000-b7fac000 rw-p 0001b000 08:04 26076690                          
/lib/ld-2.5.so
bf7cd000-bf803000 rw-p 7ffffffc8000 00:00 0                             
[stack]

VM Arguments:
jvm_args: -Xmx800M -Xms800M 
java_command: craftbukkit.jar nogui
Launcher Type: SUN_STANDARD

Environment Variables:
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
LD_LIBRARY_PATH=/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/client:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/../lib/i386
SHELL=/bin/bash

Signal Handlers:
SIGSEGV: [libjvm.so+0x43f7a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGBUS: [libjvm.so+0x43f7a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGFPE: [libjvm.so+0x35a1e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGPIPE: [libjvm.so+0x35a1e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGXFSZ: [libjvm.so+0x35a1e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGILL: [libjvm.so+0x35a1e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGUSR2: [libjvm.so+0x35cdf0], sa_mask[0]=0x00000000, sa_flags=0x10000004
SIGHUP: [libjvm.so+0x35b880], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGINT: [libjvm.so+0x35b880], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGTERM: [libjvm.so+0x35b880], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGQUIT: [libjvm.so+0x35b880], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004


---------------  S Y S T E M  ---------------

OS:CentOS release 5.6 (Final)

uname:Linux 2.6.18-274.7.1.el5.028stab095.1 #1 SMP Mon Oct 24 20:49:24 MSD 2011
i686
libc:glibc 2.5 NPTL 2.5 
rlimit: STACK 10240k, CORE 0k, NPROC 90112, NOFILE 1024, AS infinity
load average:1.04 1.29 1.47

/proc/meminfo:
MemTotal:      1155072 kB
MemFree:             0 kB
Buffers:             0 kB
Cached:              0 kB
SwapCached:          0 kB
Active:              0 kB
Inactive:            0 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:      1155072 kB
LowFree:             0 kB
SwapTotal:           0 kB
SwapFree:            0 kB
Dirty:               0 kB
Writeback:           0 kB
AnonPages:           0 kB
Mapped:              0 kB
Slab:                0 kB
PageTables:          0 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:         0 kB
Committed_AS:        0 kB
VmallocTotal:        0 kB
VmallocUsed:         0 kB
VmallocChunk:        0 kB
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
Hugepagesize:     2048 kB


CPU:total 1 (2 cores per cpu, 2 threads per core) family 6 model 37 stepping 5,
cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, ht

Memory: 4k page, physical 1155072k(467080k free), swap 8241336k(8241108k free)

vm_info: OpenJDK Client VM (20.0-b11) for linux-x86 JRE (1.6.0_22-b22), built
on Feb 23 2012 21:17:28 by "mockbuild" with gcc 4.1.2 20080704 (Red Hat
4.1.2-52)

time: Sat Apr  7 07:36:36 2012
elapsed time: 29467 seconds?

-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

From omajid at redhat.com  Sun Apr  8 15:47:29 2012
From: omajid at redhat.com (Omair Majid)
Date: Sun, 08 Apr 2012 18:47:29 -0400
Subject: [fyi] [icedtea-web] xmx for emma
In-Reply-To: <4F7F0C5B.6090500@redhat.com>
References: <4F7F0C5B.6090500@redhat.com>
Message-ID: <4F821581.1090908@redhat.com>

On 04/06/2012 11:31 AM, Jiri Vanek wrote:
> Hi! Recently codecoverage have fallen on my test machines because of not
> enough heap space. I would like to increase its Xmx value (eg to 2g as
> I'm doing in this patch)

Perhaps you might want to rename EMMA_XMX to EMMA_JAVA_ARGS? That would
allow us to add additional java arguments for emma in the future without
further changes.

> 2012-04-06  Jiri Vanek <jvanek at redhat.com>
> 
>     jvms running emma enlarged max heap space
>     * Makefile.am: (stamps/run-unit-test-code-coverage.stamp),

You should leave out the colon here.

> (stamps/run-reproducers-test-code-coverage.stamp) and

You should just use a "," instead of the "and" at the end of the line. I
believe that's the correct thing to do based on the GNU ChangeLog
guidelines.

> (run-test-code-coverage) java emma calls have increased theirs -Xmx value

Please use a colon here followed by what the new change does. How about
something like this:

(run-test-code-coverage): Use a larger max heap size for emma.

Cheers,
Omair


From omajid at redhat.com  Sun Apr  8 15:56:52 2012
From: omajid at redhat.com (Omair Majid)
Date: Sun, 08 Apr 2012 18:56:52 -0400
Subject: [rfc] [icedtea-web] blacklist for reproducers
In-Reply-To: <4F7EE803.4060401@redhat.com>
References: <4F7EE803.4060401@redhat.com>
Message-ID: <4F8217B4.7050308@redhat.com>

On 04/06/2012 08:56 AM, Jiri Vanek wrote:
> Hi!
> 
> This is second from total of 5 patches which are introducing Tets For
> Applets[1]
> 
> Thus particular one is introducing  blacklist. The test-engine is
> delivered to class-path together with all reproducers' testcases. If the
> file form engine is interface, have no @Test methods or does not meet
> constructor requirements, then the file fails, and this is making our
> statistics misleading.
> Also I'm expecting growing of engine (now I'm planing @bug and @browser
> annotations and some more logic around. See content of ignore-list after
> all this changes[2]. Also I would like to refactor ServerAccess class
> little bit in long term (as it have grown littlebit and have to much
> inner classes right now) future...
> 
> Probably cleaner solution will be to separate testengine from testaces
> more then it is now, but I have tried this refactoring and I was getting
> deeper and deeper and it was bringing more and more issues. From this
> I'm really for blacklist rather then for refactoring.
> Also one more benefit is here - you can easili blacklist all reproducers
> except one or two fro make ;)

I feel rather uncomfortable with this. I really think the underlying
problem should be fixed instead. Using band-aids like this works in the
short-term but makes icedtea-web worse in the long term.

If there is some effort required to fix the test-engine, lets do that.
If the tests are wrong, lets remove them. If it makes sense to run only
a few tests, adding that would be pretty nice (like how jtreg does it by
allowing a user to specify a directory to find tests in) but a blacklist
looks really fishy.

Omair


From omajid at redhat.com  Sun Apr  8 16:18:54 2012
From: omajid at redhat.com (Omair Majid)
Date: Sun, 08 Apr 2012 19:18:54 -0400
Subject: [RFC][icedtea-web] Unit tests for the new updates to JarSIgner
	(incomplete)
In-Reply-To: <4F7F66C2.8060506@redhat.com>
References: <4F7A1037.7060405@redhat.com> <4F7CDAF7.6090503@redhat.com>
	<4F7F66C2.8060506@redhat.com>
Message-ID: <4F821CDE.9090101@redhat.com>

On 04/06/2012 05:57 PM, Danesh Dadachanji wrote:
> On 04/04/12 07:36 PM, Omair Majid wrote:
>> On 04/02/2012 04:46 PM, Danesh Dadachanji wrote:
>>> My understanding of the idea behind verifyJar is that it does 2 somewhat
>>> separate tasks. First, given a jar, iterate over all of its entries. For
>>> every entry that can be signed, go through the list of signers and see
>>> if any have issues. If they do, setup the flags accordingly (issues
>>> could be expiry/bad key usage/not yet valid start date etc). Also, keep
>>> track of the number of entries each signer has signed, as well as the
>>> total number of possible signable entries. The second step is going
>>> through all of the signers after all the entries have been iterated over
>>> to see if there is a common signer that has signed them all. If there is
>>> any entry that is not signed but should be, or if there is one entry
>>> that does not share a common signer between all other entries, then this
>>> jar is considered UNSIGNED. If all entries (that should be signed) share
>>> a common signer, then the signer itself is checked. If the signer has
>>> signing issues, the jar is considered SIGNED_NOT_OKAY, if it has no
>>> signing issues, the jar is considered SIGNED_OK.
>>>
>>
>> This does make sense to me. Something that sort of jumps out at me is
>> that these two responsibilities are fairly distinct. It seems like it
>> might be worth it to split it into two distinct objects, each taking
>> care of one responsibility. That is, one objects determines if it should
>> be considered signed or unsigned, and another checks that (if signed)
>> the signing certificate is good.
>>
> 
> Hmm interesting idea, it makes sense to separate the checking/setup of
> the signers and the checking of the jar. However, I would like to get
> back to you on this once I have wondered into the mess that is
> verifyJars(). I think there is definitely potential here to move bits
> into another class but I don't fully know what is needed by the rest of
> JarCertVerifier. Until I do, I would rather avoid refactoring this until
> it is needed.

Yeah, that's fine. Lets not try to do too much in one patch :)

>>> Comments are very appreciated!
>>
>> Some more whitespace might be nice (to separate the asserts from the
>> code that sets up the preconditions and code that tests the object). We
>> may also want to split off the separate responsibilities into separate
>> classes. Still, I think it looks fantastic for now. Nicely done!
> 
> Separate responsibilities WRT what exactly?
> 
> The whitespaces definitely do help! =)
> 
> I've attached a new patch that loosens up the code a bit, I've padded
> newlines above (and below) the chunk of asserts. There are a few more
> modifications as follows.
> 
> 1) The new patch also brings in the changeset that renames JarSigner to
> JarCertVerifier[1] so hopefully it won't throw reviewers off too much.

Great :)

> 2) In the tests that run 1 entry than 3 entries, I've reset
> JarCertVerifier to a new instance when the three-entry vector is used. I
> think this may cause confusion later on because there would have been
> cases where the JarCertVerifier would have totalSignableEntries = 4
> instead of 3.

Hm... If you are doing this, I would recommend you go all the way and
split the 1-entry/3-entry tests into different methods to isolate the
tests completely.

> 3) Lastly, I've added a new set of asserts using the following two methods:
> 
>     /**
>      * Checks if the provided cert path has signed any of the jars
> associated
>      * with the cert verifier.
>      * @param certPath The cert path of the potential signer.
>      * @return Whether or not the cert path represents one of the
> signers of
>      * a jar associated with the verifier.
>      */
>     boolean hasJarSigner(CertPath certPath)

The name is not very descriptive. How about something like
certHasSignedAnyJar? Also, why a certPath instead of a cert?

>     /**
>      * Calculate the number of signers all the jars have in total.
>      *
>      * Note this is not the number of common signers across all jars. It is
>      * the number of common signers each jar has with respect to itself,
>      * totalled together across the other jars.
>      * @return The number of signers that have signed at least one jar
> entirely.
>      */
>     int numSigners()
> 

Likewise, this name doesn't convey much. I am still trying to figure out
what this method does.

Are these methods public? Any reason why we are adding these (or are
they just for tests)gf?

Thanks,
Omair


From thomas at m3y3r.de  Mon Apr  9 14:31:34 2012
From: thomas at m3y3r.de (Thomas Meyer)
Date: Mon, 09 Apr 2012 23:31:34 +0200
Subject: [RFC][icedtea-web] remove redundant loading/storing of cache
	file was : Re: [RFC] Fix IndexOutOfBoundException because of corrupted
	entry in recently_used file
In-Reply-To: <4F7EBD86.6040402@redhat.com>
References: <1332938501.1397.15.camel@localhost.localdomain>
	<4F79A620.2090702@redhat.com>
	<1333447622.5010.11.camel@localhost.localdomain>
	<4F7AE134.7080500@redhat.com>
	<1333458882.5010.14.camel@localhost.localdomain>
	<4F7B0E34.7010209@redhat.com>
	<1333551460.6613.13.camel@localhost.localdomain>
	<4F7D9742.4010608@redhat.com>
	<1333632651.6613.43.camel@localhost.localdomain>
	<1333639067.6613.45.camel@localhost.localdomain>
	<4F7EBD86.6040402@redhat.com>
Message-ID: <1334007094.1431.5.camel@localhost.localdomain>

Am Freitag, den 06.04.2012, 11:55 +0200 schrieb Jiri Vanek:
> On 04/05/2012 05:17 PM, Thomas Meyer wrote:
> > Am Donnerstag, den 05.04.2012, 15:30 +0200 schrieb Thomas Meyer:
> >>>> >  >  >  --- a/netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java	Wed Mar 28 12:08:10 2012 +0200
> >>>> >  >  >  +++ b/netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java	Wed Apr 04 16:48:09 2012 +0200
> >>>> >  >  >  @@ -107,6 +107,49 @@
> >>>> >  >  >          */
> >>>> >  >  >         public synchronized void load() {
> >>>> >  >  >             cacheOrder.load();
> >>>> >  >  >  +
> >>>> >  >  >  +        /*
> >>>> >  >  >  +         * clean up possibly corrupted entries
> >>>> >  >  >  +         */
> >>> >  >  It is interesting to see how many times is  checkData called during single jar run.. I counted
> >>> >  >  10executions.... But fixing this is definitely work for different patch.
> >> >
> >> >  yeah, I also noticed this. maybe this can be reduced a bit. see below
> >> >  comment for getCacheFile(). but as the recently_used file could be
> >> >  corrupted by another jvm process (etc.), we need to check this on every
> >> >  load.
> >> >
> > maybe the attached patch helps here?
> >
> > with kind regards
> > thomas
> >
> >
> >
> > reduce-number-of-loads-and-stores.patch
> >
> >
> > diff -r 44a2eea54ac8 netx/net/sourceforge/jnlp/cache/CacheUtil.java
> > --- a/netx/net/sourceforge/jnlp/cache/CacheUtil.java	Wed Apr 04 16:01:21 2012 +0200
> > +++ b/netx/net/sourceforge/jnlp/cache/CacheUtil.java	Thu Apr 05 17:14:56 2012 +0200
> > @@ -301,12 +301,18 @@
> >           synchronized (lruHandler) {
> >               lruHandler.lock();
> >
> > -            // We need to reload the cacheOrder file each time
> > -            // since another plugin/javaws instance may have updated it.
> > -            lruHandler.load();
> >               cacheFile = getCacheFileIfExist(urlToPath(source, ""));
> > +            if(cacheFile == null) { // We did not find a copy of it.
> > +                // reload the cacheOrder file since another plugin/javaws instance may have updated it.
> > +                lruHandler.load();
> > +                cacheFile = getCacheFileIfExist(urlToPath(source, ""));
> > +            }
> > +
> >               if (cacheFile == null) { // We did not find a copy of it.
> > -                cacheFile = makeNewCacheFile(source, version);
> > +                cacheFile = makeNewCacheFile(source, version, false);
> > +            } else {
> > +                // we did find and did update an entry, store it
> > +                lruHandler.store();
> >               }
> >               lruHandler.unlock();
> >           }
> > @@ -360,10 +366,11 @@
> >        * @param version the version id of the local file
> >        * @return the file location in the cache.
> >        */
> > -    public static File makeNewCacheFile(URL source, Version version) {
> > +    public static File makeNewCacheFile(URL source, Version version, boolean load) {
> >           synchronized (lruHandler) {
> >               lruHandler.lock();
> > -            lruHandler.load();
> > +            if(load == true)
> > +                lruHandler.load();
> >
> >               File cacheFile = null;
> >               for (long i = 0; i<  Long.MAX_VALUE; i++) {
> > diff -r 44a2eea54ac8 netx/net/sourceforge/jnlp/cache/ResourceTracker.java
> > --- a/netx/net/sourceforge/jnlp/cache/ResourceTracker.java	Wed Apr 04 16:01:21 2012 +0200
> > +++ b/netx/net/sourceforge/jnlp/cache/ResourceTracker.java	Thu Apr 05 17:14:56 2012 +0200
> > @@ -786,7 +786,7 @@
> >                       entry.markForDelete();
> >                       entry.store();
> >                       // Old entry will still exist. (but removed at cleanup)
> > -                    localFile = CacheUtil.makeNewCacheFile(resource.location, resource.downloadVersion);
> > +                    localFile = CacheUtil.makeNewCacheFile(resource.location, resource.downloadVersion, true);
> >                       CacheEntry newEntry = new CacheEntry(resource.location, resource.requestVersion);
> >                       newEntry.lock();
> >                       entry.unlock();
> >
> 
> 
> Hmm. As I see it, this is removing some load() but is adding store(). I think that in case of 
> parallel javawss redundant reading does not hurt but more writing can hurt a lot.

Yes, you are right. this patch does the wrong thing.

Another idea to decrease number of reads:

I thought about storing the file timestamp of the last modification
after store() and compare this timestamp in the load() method, if the
timestamp differs we need to reload the file. if not we can skip the
load. what do you think about this idea?

> 
>  From my point of view I would rather stay without this fix - unless some more serious occurrences 
> will rise from this issue.
> 
> Ok?

okay.

> 
> Best regards,
>    J.





From thomas at m3y3r.de  Mon Apr  9 15:04:35 2012
From: thomas at m3y3r.de (Thomas Meyer)
Date: Tue, 10 Apr 2012 00:04:35 +0200
Subject: [RFC] Fix IndexOutOfBoundException because of corrupted entry
	in recently_used file
In-Reply-To: <4F7EBEEF.4070405@redhat.com>
References: <1332938501.1397.15.camel@localhost.localdomain>
	<4F79A620.2090702@redhat.com>
	<1333447622.5010.11.camel@localhost.localdomain>
	<4F7AE134.7080500@redhat.com>
	<1333458882.5010.14.camel@localhost.localdomain>
	<4F7B0E34.7010209@redhat.com>
	<1333551460.6613.13.camel@localhost.localdomain>
	<4F7D9742.4010608@redhat.com>
	<1333632651.6613.43.camel@localhost.localdomain>
	<4F7EBEEF.4070405@redhat.com>
Message-ID: <1334009075.1431.14.camel@localhost.localdomain>

Am Freitag, den 06.04.2012, 12:01 +0200 schrieb Jiri Vanek:
+    /**
+     * This is breaking paths in second part of cache file item
+     * @throws Exception
+     */
+    @Test
+    public void coruptAndRunCache3() throws Exception {
+        clearAndEvaluateCache();
+        evaluateSimpleTest1OkCache(runSimpleTest1());
+        assertCacheIsNotEmpty();
+        breakCache3();
+        ProcessResult pr = runSimpleTest1();
+        assertAoobNOTappeared(pr);

In the current code the StringIndexOutOfBoundsExceptions is only printed
in verbose mode in netx/net/sourceforge/jnlp/cache/ResourceTracker.java
in the private class Downloader in this catch:

                try {

                    // Resource processing involves writing to files 
                    // (cache entry trackers, the files themselves, etc.)
                    // and it therefore needs to be privileged

                    final Resource fResource = resource;
                    AccessController.doPrivileged(new PrivilegedAction<Void>() {
                        public Void run() {
                            processResource(fResource);                            
                            return null;
                        }
                    });

                } catch (Exception ex) {
                    if (JNLPRuntime.isDebug())
->                        ex.printStackTrace();
                }

the Exception itself is thrown at CacheUtil.getCacheFileIfExist() -> pathToURLPath()

    private static String pathToURLPath(String path) {
        int len = cacheDir.length();
        int index = path.indexOf(File.separatorChar, len + 1);
->        return path.substring(index);
    }

+        assertLruExceptionAppeared(pr);
+        evaluateSimpleTest1OkCache(pr);
+        ProcessResult pr3 = runSimpleTest1();
+        evaluateSimpleTest1OkCache(pr3);
+        assertLruExceptionNOTappeared(pr3);
+        clearAndEvaluateCache();
+        ProcessResult pr2 = runSimpleTest1();
+        evaluateSimpleTest1OkCache(pr2);
+        assertLruExceptionNOTappeared(pr2);
+    }

I'm not sure if this test case does the right thing.

kind regards
thomas





From jvanek at redhat.com  Tue Apr 10 01:19:36 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Tue, 10 Apr 2012 10:19:36 +0200
Subject: [RFC] Fix IndexOutOfBoundException because of corrupted entry
	in recently_used file
In-Reply-To: <1334009075.1431.14.camel@localhost.localdomain>
References: <1332938501.1397.15.camel@localhost.localdomain>
	<4F79A620.2090702@redhat.com>
	<1333447622.5010.11.camel@localhost.localdomain>
	<4F7AE134.7080500@redhat.com>
	<1333458882.5010.14.camel@localhost.localdomain>
	<4F7B0E34.7010209@redhat.com>
	<1333551460.6613.13.camel@localhost.localdomain>
	<4F7D9742.4010608@redhat.com>
	<1333632651.6613.43.camel@localhost.localdomain>
	<4F7EBEEF.4070405@redhat.com>
	<1334009075.1431.14.camel@localhost.localdomain>
Message-ID: <4F83ED18.3060102@redhat.com>

On 04/10/2012 12:04 AM, Thomas Meyer wrote:
> Am Freitag, den 06.04.2012, 12:01 +0200 schrieb Jiri Vanek:
> +    /**
> +     * This is breaking paths in second part of cache file item
> +     * @throws Exception
> +     */
> +    @Test
> +    public void coruptAndRunCache3() throws Exception {
> +        clearAndEvaluateCache();
> +        evaluateSimpleTest1OkCache(runSimpleTest1());
> +        assertCacheIsNotEmpty();
> +        breakCache3();
> +        ProcessResult pr = runSimpleTest1();
> +        assertAoobNOTappeared(pr);
>
> In the current code the StringIndexOutOfBoundsExceptions is only printed
> in verbose mode in netx/net/sourceforge/jnlp/cache/ResourceTracker.java
> in the private class Downloader in this catch:

Yy, and patch is launching javaws in verbose mode;)
>
>                  try {
>
>                      // Resource processing involves writing to files
>                      // (cache entry trackers, the files themselves, etc.)
>                      // and it therefore needs to be privileged
>
>                      final Resource fResource = resource;
>                      AccessController.doPrivileged(new PrivilegedAction<Void>() {
>                          public Void run() {
>                              processResource(fResource);
>                              return null;
>                          }
>                      });
>
>                  } catch (Exception ex) {
>                      if (JNLPRuntime.isDebug())
> ->                         ex.printStackTrace();
>                  }
>
> the Exception itself is thrown at CacheUtil.getCacheFileIfExist() ->  pathToURLPath()
>
>      private static String pathToURLPath(String path) {
>          int len = cacheDir.length();
>          int index = path.indexOf(File.separatorChar, len + 1);
> ->         return path.substring(index);
>      }
>
> +        assertLruExceptionAppeared(pr);
> +        evaluateSimpleTest1OkCache(pr);
> +        ProcessResult pr3 = runSimpleTest1();
> +        evaluateSimpleTest1OkCache(pr3);
> +        assertLruExceptionNOTappeared(pr3);
> +        clearAndEvaluateCache();
> +        ProcessResult pr2 = runSimpleTest1();
> +        evaluateSimpleTest1OkCache(pr2);
> +        assertLruExceptionNOTappeared(pr2);
> +    }
>
> I'm not sure if this test case does the right thing.

so I thing it does....
>
> kind regards
> thomas
>
>
>



From jvanek at redhat.com  Tue Apr 10 02:04:31 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Tue, 10 Apr 2012 11:04:31 +0200
Subject: [fyi] [icedtea-web] xmx for emma
In-Reply-To: <4F821581.1090908@redhat.com>
References: <4F7F0C5B.6090500@redhat.com> <4F821581.1090908@redhat.com>
Message-ID: <4F83F79F.4020806@redhat.com>

On 04/09/2012 12:47 AM, Omair Majid wrote:
> On 04/06/2012 11:31 AM, Jiri Vanek wrote:
Hi Omair!
Thanx for check:)
>> Hi! Recently codecoverage have fallen on my test machines because of not
>> enough heap space. I would like to increase its Xmx value (eg to 2g as
>> I'm doing in this patch)
>
> Perhaps you might want to rename EMMA_XMX to EMMA_JAVA_ARGS? That would
> allow us to add additional java arguments for emma in the future without
> further changes.
Yap. Why not:)
>
>> 2012-04-06  Jiri Vanek<jvanek at redhat.com>
>>
>>      jvms running emma enlarged max heap space
>>      * Makefile.am: (stamps/run-unit-test-code-coverage.stamp),
>
> You should leave out the colon here.
>
>> (stamps/run-reproducers-test-code-coverage.stamp) and
>
> You should just use a "," instead of the "and" at the end of the line. I
> believe that's the correct thing to do based on the GNU ChangeLog
> guidelines.
>
>> (run-test-code-coverage) java emma calls have increased theirs -Xmx value
>
> Please use a colon here followed by what the new change does. How about
> something like this:
>
> (run-test-code-coverage): Use a larger max heap size for emma.
>
> Cheers,
> Omair

2012-04-10  Jiri Vanek <jvanek at redhat.com>

	* Makefile.am: EMMA_JAVA_ARGS, new variable for adjusting emma runs.
	Currently set to -Xmx2G
	(stamps/run-unit-test-code-coverage.stamp),
	(stamps/run-reproducers-test-code-coverage.stamp),
	(run-test-code-coverage) Use EMMA_JAVA_ARGS in theirs emma runs.

Better?


Best regards,
  J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: emmaXmx2.diff
Type: text/x-patch
Size: 2623 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120410/2fe3afa5/emmaXmx2.diff 

From jvanek at redhat.com  Tue Apr 10 02:11:40 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Tue, 10 Apr 2012 11:11:40 +0200
Subject: [rfc][icedtea-web] rewritten xfork test
In-Reply-To: <4F7F0AB2.8070201@redhat.com>
References: <4F6B1821.2040600@redhat.com> <4F7F0AB2.8070201@redhat.com>
Message-ID: <4F83F94C.5020801@redhat.com>

On 04/06/2012 05:24 PM, Pavel Tisnovsky wrote:
> Jiri Vanek wrote:
>> Inspired by Omair's effort to reduce failing tests, I have rewritten
>> deadlock tests, which were failing quite randomly in half of the cases.
>> It was caused by delayed removing of zombies after process have time-outed.
>>
>> By this patch, ignorelist which I have proposed two days ago (and will
>> do again soon as separate patch) to ignore no-testable classes (eg
>> interfaces), and fixes from [RFC][icedtea-web] fixes to reproducer
>> engine, we will be on three  failing reproducers ("spaces" ) and  with
>> occasional cache test fill.
>>
>> All those five -  two sometimes, three regularly - failing reproducers
>> are the same issue we are talking  in [icedtea-web] RFC: disable tests
>> that are known to fail thread. - they are representing issue., but...:)
>>
>>
>>
>> 2012-03-22  Jiri Vanek<jvanek at redhat.com>
>>
>>      Rewritten DeadLockTestTest to stop failing in more then 1/2 of cases
>>      All assassinated processes were hanging as zombies, killed forcibly by
>>      kill -9 now.
>>      *
>> /tests/jnlp_tests/simple/deadlocktest/testcases/DeadLockTestTest.java:
>>      (countJavaInstances) now return pids of found javas.
>>      (killDiff) new method killing zombie javas forcibly.
>>
>
> Hi Jiri,
>
> could you please fix following typos in the test tool?
>
> "This process is hanging more th_e_n"
>
> "...but isnt!"
>            ^    (on more places)
>
> "proces inside background deadlock cant be null. Was."
>                                       ^           It ^
>
> "lunched JVMs must be exactly 2"
>    ^  (this one is funny :-)
>

Yap. fixed. The changes which were not part of this changeset but were noticed will follow as 
additional changeset.

Ok now?

Thanx foe check.
  J.
>
> Thank you in advance,
> Pavel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rewrittenXforkTests2.diff
Type: text/x-patch
Size: 9715 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120410/abcede99/rewrittenXforkTests2.diff 

From jvanek at redhat.com  Tue Apr 10 04:42:48 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Tue, 10 Apr 2012 13:42:48 +0200
Subject: [rfc] [icedtea-web] blacklist for reproducers
In-Reply-To: <4F8217B4.7050308@redhat.com>
References: <4F7EE803.4060401@redhat.com> <4F8217B4.7050308@redhat.com>
Message-ID: <4F841CB8.9000004@redhat.com>

On 04/09/2012 12:56 AM, Omair Majid wrote:
> On 04/06/2012 08:56 AM, Jiri Vanek wrote:
>> Hi!
>>
>> This is second from total of 5 patches which are introducing Tets For
>> Applets[1]
>>
>> Thus particular one is introducing  blacklist. The test-engine is
>> delivered to class-path together with all reproducers' testcases. If the
>> file form engine is interface, have no @Test methods or does not meet
>> constructor requirements, then the file fails, and this is making our
>> statistics misleading.
>> Also I'm expecting growing of engine (now I'm planing @bug and @browser
>> annotations and some more logic around. See content of ignore-list after
>> all this changes[2]. Also I would like to refactor ServerAccess class
>> little bit in long term (as it have grown littlebit and have to much
>> inner classes right now) future...
>>
>> Probably cleaner solution will be to separate testengine from testaces
>> more then it is now, but I have tried this refactoring and I was getting
>> deeper and deeper and it was bringing more and more issues. From this
>> I'm really for blacklist rather then for refactoring.
>> Also one more benefit is here - you can easili blacklist all reproducers
>> except one or two fro make ;)
I was  afraid you will say something like this...
>
> I feel rather uncomfortable with this. I really think the underlying
> problem should be fixed instead. Using band-aids like this works in the
> short-term but makes icedtea-web worse in the long term.
>
> If there is some effort required to fix the test-engine, lets do that.
> If the tests are wrong, lets remove them. If it makes sense to run only
> a few tests, adding that would be pretty nice (like how jtreg does it by
> allowing a user to specify a directory to find tests in) but a blacklist
> looks really fishy.
>
> Omair

So lets dig what is necessary to do.
We have

netx directory with sources of nex
??? javax
?   ??? jnlp
??? net
     ??? sourceforge
         ??? jnlp
...
         ?   ??? tools
         ?   ??? util
...
         ??? nanoxml

and we have
tests directory with
??? jnlp_tests  - source files and testcases for reproducers
?   ??? signed
...
?   ??? simple
...
??? junit-runner - launcher for both testsuites
??? netx - directory containg  unittests, pac tests, *infrastructure for reproducers* and *tests of 
infrastructure* (virtual server...)
?   ??? jnlp_testsengine - *both* infrastructure for reproducers *and* tests of infrastructure
?   ?   ??? net
?   ?       ??? sourceforge
?   ?           ??? jnlp
?   ??? pac - sources of pac tests
?   ??? unit - sources of unittests
?       ??? net
?           ??? sourceforge
?               ??? jnlp
?                   ??? application
?                   ??? runtime
?                   ??? templates
?                   ??? util
?                       ??? replacements


The we have compile-time and run-time dependencies in makefile (I'm usinf sources locations instead 
of tests.build in this text wilfully)
They are currently :
compile-time of unittests:
netx and tests/netx/unit
run-time of unittests:
junit-runner netx and tests/netx/unit


compile-time of reproducer's sources:
netx  and tests/jnlp_tests/signed|simple/reproducer/src/
compile-time of reproducer's testcases:
netx tests/netx/jnlp_testsengine  and tests/jnlp_tests/signed|simple/reproducer/testcase/ (all 
testcases together)

runtime-time of reproducer's sources:
junit-runner  netx  and from its jnlp/html (mostly in  jnlp_tests_server with jars created from 
tests/jnlp_tests/signed|simple/sources/testcase/)
run-time of reproducer's testcases:
junit-runner netx tests/netx/jnlp_testsengine  and 
tests/jnlp_tests/signed|simple/reproducer/testcase/(all testcases together)


And second thing is where the classes of tests are taken:

for unittests all files inisde tests/unit
for reproducers all files tests/netx/jnlp_testsengine and 
tests/jnlp_tests/signed|simple/reproducer/testcase/

The error is obvious. tests/netx/jnlp_testsengine contains both tests and logic

My opinion here will be to unify above as much as possible.
When you will check [1] for browserTests-BugAnnotation [2] you will see how few other issues "solved 
below" raised.


[1]http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-March/017799.html
[2]http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120320/8ef6bdfe/browserTests-BugAnnotation-0001.diff


1) move all tests from tests/netx/jnlp_testsengine to tests/netx/unit where they belongs IMHO
1.5) With this refactoring I would like to extract all inner classes from ServerAccess
2) fix compile and runtime class-path of unittests for tests/netx/jnlp_testsengine
3) during reproducers run launch *just* compiled testcases
4) no more tests in tests/netx/jnlp_testsengine, framework will be tested in unittests (same as (1) 
but just for ensuring..:) )
4.5) unittets and reprodyucers runs should have same classapth in runtime/compiletime. => unify them 
in some variable(s)(?)
5) I'm also for adding tests/netx/jnlp_testsengine to compile class-path of junit-runner (as it 
looks useful from [1,2] point of view.
6) Maybe after all of above done the jnlp_testsengine can be renamed and moved somewhere else. (and 
also jnlp_tests probably should be moved to tests/netx/) But This should be done as separate changeset.

1-6 - ServerAccess api should not be changed, although maybe some methods private/public/protected 
statuses will be transformed due to moving of tests)


What do you think?


For launching just some tests I would like then introduce some whitelist. The logic will be same as 
was introduced in  this discarded  patch, but default value will be ".*"  Before wanted run it will 
be possible to enter regex matching the set of reproducers determined for run.


What do you think?

J.


From omajid at redhat.com  Tue Apr 10 08:10:29 2012
From: omajid at redhat.com (Omair Majid)
Date: Tue, 10 Apr 2012 11:10:29 -0400
Subject: [fyi] [icedtea-web] xmx for emma
In-Reply-To: <4F83F79F.4020806@redhat.com>
References: <4F7F0C5B.6090500@redhat.com> <4F821581.1090908@redhat.com>
	<4F83F79F.4020806@redhat.com>
Message-ID: <4F844D65.1070106@redhat.com>

On 04/10/2012 05:04 AM, Jiri Vanek wrote:
> On 04/09/2012 12:47 AM, Omair Majid wrote:
>> On 04/06/2012 11:31 AM, Jiri Vanek wrote:
> Hi Omair!
> Thanx for check:)
>>> Hi! Recently codecoverage have fallen on my test machines because of not
>>> enough heap space. I would like to increase its Xmx value (eg to 2g as
>>> I'm doing in this patch)
>>
>> Perhaps you might want to rename EMMA_XMX to EMMA_JAVA_ARGS? That would
>> allow us to add additional java arguments for emma in the future without
>> further changes.
> Yap. Why not:)
>>
>>> 2012-04-06  Jiri Vanek<jvanek at redhat.com>
>>>
>>>      jvms running emma enlarged max heap space
>>>      * Makefile.am: (stamps/run-unit-test-code-coverage.stamp),
>>
>> You should leave out the colon here.
>>
>>> (stamps/run-reproducers-test-code-coverage.stamp) and
>>
>> You should just use a "," instead of the "and" at the end of the line. I
>> believe that's the correct thing to do based on the GNU ChangeLog
>> guidelines.
>>
>>> (run-test-code-coverage) java emma calls have increased theirs -Xmx
>>> value
>>
>> Please use a colon here followed by what the new change does. How about
>> something like this:
>>
>> (run-test-code-coverage): Use a larger max heap size for emma.
>>
>> Cheers,
>> Omair
> 
> 2012-04-10  Jiri Vanek <jvanek at redhat.com>
                        ^
An extra space here please.

> 
>     * Makefile.am: EMMA_JAVA_ARGS, new variable for adjusting emma runs.
>     Currently set to -Xmx2G
                             ^
Please add a "." here

>     (stamps/run-unit-test-code-coverage.stamp),
>     (stamps/run-reproducers-test-code-coverage.stamp),
>     (run-test-code-coverage) Use EMMA_JAVA_ARGS in theirs emma runs.
                              ^
And a ":" here

> Better?

Yup, with the suggested modifications to the ChangeLog, looks fine to me.

Cheers,
Omair


From omajid at redhat.com  Tue Apr 10 08:38:34 2012
From: omajid at redhat.com (Omair Majid)
Date: Tue, 10 Apr 2012 11:38:34 -0400
Subject: [rfc] [icedtea-web] blacklist for reproducers
In-Reply-To: <4F841CB8.9000004@redhat.com>
References: <4F7EE803.4060401@redhat.com> <4F8217B4.7050308@redhat.com>
	<4F841CB8.9000004@redhat.com>
Message-ID: <4F8453FA.2040606@redhat.com>

On 04/10/2012 07:42 AM, Jiri Vanek wrote:
> I was  afraid you will say something like this...

You know me too well ;)

> So lets dig what is necessary to do.
> We have

[ snip lots of analysis ]

Thanks for the in-depth analysis.

And I agree; jnlp_testengine contains too much and does not really
belong there.

> 1) move all tests from tests/netx/jnlp_testsengine to tests/netx/unit
> where they belongs IMHO

A slightly different approach might be to move jnlp_testsengine itself
to a top level directory in icedtea-web. jnlp_testsengine isn't a test
itself so I would be happy if we moved it out from under tests/. I dont
think moving the tests from tests/netx/jnlp_testsengine to
tests/netx/unit is a good idea; they are not netx's tests. How about
creating another directory (jnlp_testengine under tests/) to contain
tests for the jnlp_engine itself? (which are distinct from netx's or the
plugin's tests).

> 1.5) With this refactoring I would like to extract all inner classes
> from ServerAccess

+1 from me

> 2) fix compile and runtime class-path of unittests for
> tests/netx/jnlp_testsengine

This sounds fine.

> 3) during reproducers run launch *just* compiled testcases

Could you clarify what you mean here?

> 4) no more tests in tests/netx/jnlp_testsengine, framework will be
> tested in unittests (same as (1) but just for ensuring..:) )

See my points for 1, then :)

> 4.5) unittets and reprodyucers runs should have same classapth in
> runtime/compiletime. => unify them in some variable(s)(?)

No objections here (if it works, of course; there may be some subtle
issues).

> 5) I'm also for adding tests/netx/jnlp_testsengine to compile class-path
> of junit-runner (as it looks useful from [1,2] point of view.

I haven't seen [1] or [2] yet. But we can consider that separately,
right? I am not opposed to it - but let's consider that on it's own merits.

> 6) Maybe after all of above done the jnlp_testsengine can be renamed and
> moved somewhere else. (and also jnlp_tests probably should be moved to
> tests/netx/) But This should be done as separate changeset.

I was going to suggest that myself. +1

> 1-6 - ServerAccess api should not be changed, although maybe some
> methods private/public/protected statuses will be transformed due to
> moving of tests)

It's not a public API, so we can live with making changes to it, though
it wont be pretty. And reviewing it will be painful.

> What do you think?

This sounds fantastic!

> For launching just some tests I would like then introduce some
> whitelist. The logic will be same as was introduced in  this discarded 
> patch, but default value will be ".*"  Before wanted run it will be
> possible to enter regex matching the set of reproducers determined for run.

Sure, that sounds great; I am very happy with this. I would be happy to
review the patches, but please try and keep them small/separate.

Cheers,
Omair


From meyert at icedtea.classpath.org  Tue Apr 10 10:16:32 2012
From: meyert at icedtea.classpath.org (meyert at icedtea.classpath.org)
Date: Tue, 10 Apr 2012 17:16:32 +0000
Subject: /hg/icedtea-web: Validate the recently_used file at every load. ...
Message-ID: <hg.60ef5191add3.1334078192.8643924302249223276@icedtea.classpath.org>

changeset 60ef5191add3 in /hg/icedtea-web
details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=60ef5191add3
author: Thomas Meyer <thomas at m3y3r.de>
date: Tue Apr 10 19:10:43 2012 +0200

	Validate the recently_used file at every load. This will fix the StringIndex-
	OutOfBoundsException for a corrupted path entry thrown in
	CacheUtil.pathToURLPath(). This Exception was catched in
	RessourceTracker.Downloader.run() and only printed in debug mode.


diffstat:

 ChangeLog                                                                  |   21 +
 Makefile.am                                                                |   16 +-
 netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java                       |   65 ++++-
 netx/net/sourceforge/jnlp/cache/CacheUtil.java                             |  135 +++------
 netx/net/sourceforge/jnlp/resources/Messages.properties                    |    9 +-
 tests/jnlp_tests/signed/CacheReproducer/testcases/CacheReproducerTest.java |   93 +++++-
 6 files changed, 217 insertions(+), 122 deletions(-)

diffs (truncated from 563 to 500 lines):

diff -r cde6d59a2901 -r 60ef5191add3 ChangeLog
--- a/ChangeLog	Thu Apr 05 10:57:16 2012 -0400
+++ b/ChangeLog	Tue Apr 10 19:10:43 2012 +0200
@@ -1,3 +1,24 @@
+2012-06-04  Jiri Vanek <jvanek at redhat.com>
+            Thomas Meyer <thomas at m3y3r.de>
+
+        * makefile.am: (stamps/run-netx-dist-tests.stamp) and
+                       (run-reproducers-test-code-coverage.stamp)
+        now using $(javaws) variable instead of plaintext javaws
+        * netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java: (checkData) new
+        method checking for sanity of cache entries
+        (load) now checks for data sanity after loading, and stores without
+        corrupted items if necessary
+        (Comparator.compare) for sorting lru items. Now redundant checking for
+        sanity removed
+        * netx/net/sourceforge/jnlp/cache/CacheUtil.java: (getCacheFile) don't
+        call lruHandler.store twice for new cache entries
+        (getCacheFileIfExist) removed iteration and cleaning mechanism
+        * netx/net/sourceforge/jnlp/resources/Messages.properties: modified
+        cache messages
+        * tests/jnlp_tests/signed/CacheReproducer/testcases/CacheReproducerTest.java
+        Added test for checking corrupted path in entry and all tests adapted for
+        exception thrown only in debug mode
+
 2012-04-04  Danesh Dadachanji  <ddadacha at redhat.com>
 	Change the name of JarSigner to JarCertVerifier to make it more
 	relevant to the purpose of the file.
diff -r cde6d59a2901 -r 60ef5191add3 Makefile.am
--- a/Makefile.am	Thu Apr 05 10:57:16 2012 -0400
+++ b/Makefile.am	Tue Apr 10 19:10:43 2012 +0200
@@ -565,7 +565,7 @@
 	cd $(JNLP_TESTS_ENGINE_DIR) ; \
 	class_names=`cat $(REPRODUCERS_CLASS_NAMES)` ; \
 	CLASSPATH=$(NETX_DIR)/lib/classes.jar:$(JUNIT_JAR):$(JUNIT_RUNNER_JAR):. \
-	  $(BOOT_DIR)/bin/java -Dtest.server.dir=$(JNLP_TESTS_SERVER_DEPLOYDIR) -Djavaws.build.bin=$(DESTDIR)$(bindir)/javaws \
+	  $(BOOT_DIR)/bin/java -Dtest.server.dir=$(JNLP_TESTS_SERVER_DEPLOYDIR) -Djavaws.build.bin=$(DESTDIR)$(bindir)/$(javaws) \
 	 -Xbootclasspath:$(RUNTIME) CommandLine $$class_names \
 	  > stdout.log 2> stderr.log ; \
 	 cat stdout.log ; \
@@ -676,9 +676,9 @@
 	$(BOOT_DIR)/bin/jar -cf $(DESTDIR)$(datadir)/$(PACKAGE_NAME)/netx.jar * ; \
 	popd ; \
 	rm -rf $$instructed_dir ; \
-	echo "patching javaws" ; \
-	cat $$javaws_backup | sed "s,$(LAUNCHER_BOOTCLASSPATH),$$nw_bootclasspath," > $(DESTDIR)$(bindir)/javaws ; \
-	chmod 777 $(DESTDIR)$(bindir)/javaws ; \
+	echo "patching $(javaws)" ; \
+	cat $$javaws_backup | sed "s,$(LAUNCHER_BOOTCLASSPATH),$$nw_bootclasspath," > $(DESTDIR)$(bindir)/$(javaws) ; \
+	chmod 777 $(DESTDIR)$(bindir)/$(javaws) ; \
 	testcases_srcs=( ) ; \
 	k=0 ; \
 	types=(simple signed); \
@@ -697,7 +697,7 @@
 	class_names=`cat $(REPRODUCERS_CLASS_NAMES)` ; \
 	$(BOOT_DIR)/bin/java  \
 	 -Dtest.server.dir=$(JNLP_TESTS_SERVER_DEPLOYDIR) \
-	 -Djavaws.build.bin=$(DESTDIR)$(bindir)/javaws \
+	 -Djavaws.build.bin=$(DESTDIR)$(bindir)/$(javaws) \
 	 -Xbootclasspath:$(RUNTIME) -cp $(EMMA_JAR) emmarun  \
 	   -raw \
 	   -cp $(NETX_DIR)/lib/classes.jar \
@@ -727,9 +727,9 @@
 	  -r xml \
 	  "$${testcases_srcs[@]}" ; \
 	echo "restoring javaws and netx.jar in $(DESTDIR)" ; \
-	rm -f $(DESTDIR)$(bindir)/javaws $(DESTDIR)$(datadir)/$(PACKAGE_NAME)/netx.jar ; \
-	rm -f $(DESTDIR)$(bindir)/javaws;  \
-	mv $$javaws_backup $(DESTDIR)$(bindir)/javaws;  \
+	rm -f $(DESTDIR)$(bindir)/$(javaws) $(DESTDIR)$(datadir)/$(PACKAGE_NAME)/netx.jar ; \
+	rm -f $(DESTDIR)$(bindir)/$(javaws);  \
+	mv $$javaws_backup $(DESTDIR)$(bindir)/$(javaws);  \
 	mv $$netx_backup $(DESTDIR)$(datadir)/$(PACKAGE_NAME)/netx.jar ; \
 	mv $(JNLP_TESTS_ENGINE_DIR)/tests-output.xml  $(JNLP_TESTS_ENGINE_DIR)/tests-output_withEmma.xml ; \
 	mv $(JNLP_TESTS_ENGINE_DIR)/tests-output.xml_noEmma  $(JNLP_TESTS_ENGINE_DIR)/tests-output.xml ; \
diff -r cde6d59a2901 -r 60ef5191add3 netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java
--- a/netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java	Thu Apr 05 10:57:16 2012 -0400
+++ b/netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java	Tue Apr 10 19:10:43 2012 +0200
@@ -36,6 +36,7 @@
  */
 package net.sourceforge.jnlp.cache;
 
+import java.util.Set;
 import static  net.sourceforge.jnlp.runtime.Translator.R;
 
 import java.io.File;
@@ -45,6 +46,7 @@
 import java.util.ArrayList;
 import java.util.Collections;
 import java.util.Comparator;
+import java.util.Iterator;
 import java.util.List;
 import java.util.Map.Entry;
 
@@ -107,6 +109,57 @@
      */
     public synchronized void load() {
         cacheOrder.load();
+        /* 
+         * clean up possibly corrupted entries
+         */
+        if (checkData()) {
+            if (JNLPRuntime.isDebug()) {
+                new LruCacheException().printStackTrace();
+            }
+            System.out.println(R("CFakeCache"));
+            store();
+            System.out.println(R("CFakedCache"));
+        }
+    }
+
+    /**
+     * check content of cacheOrder and remove invalid/corrupt entries
+     *
+     * @return true, if cache was coruupted and affected entry removed
+     */
+    private boolean checkData () {
+        boolean modified = false;
+        Set<Entry<Object, Object>> q = cacheOrder.entrySet();
+        for (Iterator<Entry<Object, Object>> it = q.iterator(); it.hasNext();) {
+            Entry<Object, Object> currentEntry = it.next();
+
+            final String key = (String) currentEntry.getKey();
+            final String path = (String) currentEntry.getValue();
+
+            // 1. check key format: "milliseconds,number"
+            try {
+                String sa[] = key.split(",");
+                Long l1 = Long.parseLong(sa[0]);
+                Long l2 = Long.parseLong(sa[1]);
+            } catch (Exception ex) {
+                it.remove();
+                modified = true;
+                continue;
+            }
+
+            // 2. check path format - does the path look correct?
+            if (path != null) {
+                if (path.indexOf(cacheDir) < 0) {
+                    it.remove();
+                    modified = true;
+                }
+            } else {
+                it.remove();
+                modified = true;
+            }
+        }
+        
+        return modified;
     }
 
     /**
@@ -174,15 +227,11 @@
         Collections.sort(entries, new Comparator<Entry<String, String>>() {
             @Override
             public int compare(Entry<String, String> e1, Entry<String, String> e2) {
-                try {
-                    Long t1 = Long.parseLong(e1.getKey().split(",")[0]);
-                    Long t2 = Long.parseLong(e2.getKey().split(",")[0]);
+                Long t1 = Long.parseLong(e1.getKey().split(",")[0]);
+                Long t2 = Long.parseLong(e2.getKey().split(",")[0]);
 
-                    int c = t1.compareTo(t2);
-                    return c < 0 ? 1 : (c > 0 ? -1 : 0);
-                } catch (Exception e) {
-                    throw new LruCacheException(R("Corrupt LRU file entries"));
-                }
+                int c = t1.compareTo(t2);
+                return c < 0 ? 1 : (c > 0 ? -1 : 0);
             }
         });
         return entries;
diff -r cde6d59a2901 -r 60ef5191add3 netx/net/sourceforge/jnlp/cache/CacheUtil.java
--- a/netx/net/sourceforge/jnlp/cache/CacheUtil.java	Thu Apr 05 10:57:16 2012 -0400
+++ b/netx/net/sourceforge/jnlp/cache/CacheUtil.java	Tue Apr 10 19:10:43 2012 +0200
@@ -307,8 +307,8 @@
             cacheFile = getCacheFileIfExist(urlToPath(source, ""));
             if (cacheFile == null) { // We did not find a copy of it.
                 cacheFile = makeNewCacheFile(source, version);
-            }
-            lruHandler.store();
+            } else
+                lruHandler.store();
             lruHandler.unlock();
         }
         return cacheFile;
@@ -323,48 +323,16 @@
     private static File getCacheFileIfExist(File urlPath) {
         synchronized (lruHandler) {
             File cacheFile = null;
-            int tries = 0;
-            List<Entry<String, String>> entries = null;
-            do {
-                try {
-                    tries++;
-                    entries = lruHandler.getLRUSortedEntries();
-                } catch (LruCacheException ex) {
-                    if (tries == 1) {
-                        ex.printStackTrace();
-                        System.out.println(R("CFakeCache"));
-                        lruHandler.clearLRUSortedEntries();
-                        lruHandler.store();
-                        System.out.println(R("CFakedCache"));
-                    } else if (tries == 2) {
-                        ex.printStackTrace();
-                        System.out.println(R("CStillCorupted"));
-                        boolean clearingresult = CacheUtil.clearCache();
-                        if (!clearingresult) {
-                            throw new InternalError(R("CCleaningUnsuccessful"));
-                        }
-                        System.out.println(R("CClearedReloading"));
-                        lruHandler.clearLRUSortedEntries();
-                        lruHandler.store();
-                        System.out.println(R("CReloadRestarting"));
-
-                    } else {
-                        throw new InternalError(R("CStillBroken"));
-                    }
-
-                }
-            } while (entries == null);
+            List<Entry<String, String>> entries = lruHandler.getLRUSortedEntries();
             // Start searching from the most recent to least recent.
             for (Entry<String, String> e : entries) {
                 final String key = e.getKey();
                 final String path = e.getValue();
 
-                if (path != null) {
-                    if (pathToURLPath(path).equals(urlPath.getPath())) { // Match found.
-                        cacheFile = new File(path);
-                        lruHandler.updateEntry(key);
-                        break; // Stop searching since we got newest one already.
-                    }
+                if (pathToURLPath(path).equals(urlPath.getPath())) { // Match found.
+                    cacheFile = new File(path);
+                    lruHandler.updateEntry(key);
+                    break; // Stop searching since we got newest one already.
                 }
             }
             return cacheFile;
@@ -561,6 +529,7 @@
      * This will remove all old cache items.
      */
     public static void cleanCache() {
+
         if (okToClearCache()) {
             // First we want to figure out which stuff we need to delete.
             HashSet<String> keep = new HashSet<String>();
@@ -579,57 +548,55 @@
             for (Entry<String, String> e : lruHandler.getLRUSortedEntries()) {
                 // Check if the item is contained in cacheOrder.
                 final String key = e.getKey();
-                final String value = e.getValue();
+                final String path = e.getValue();
 
-                if (value != null) {
-                    File file = new File(value);
-                    PropertiesFile pf = new PropertiesFile(new File(value + ".info"));
-                    boolean delete = Boolean.parseBoolean(pf.getProperty("delete"));
+                File file = new File(path);
+                PropertiesFile pf = new PropertiesFile(new File(path + ".info"));
+                boolean delete = Boolean.parseBoolean(pf.getProperty("delete"));
 
-                    /*
-                     * This will get me the root directory specific to this cache item.
-                     * Example:
-                     *  cacheDir = /home/user1/.icedtea/cache
-                     *  file.getPath() = /home/user1/.icedtea/cache/0/http/www.example.com/subdir/a.jar
-                     *  rStr first becomes: /0/http/www.example.com/subdir/a.jar
-                     *  then rstr becomes: /home/user1/.icedtea/cache/0
-                     */
-                    String rStr = file.getPath().substring(cacheDir.length());
-                    rStr = cacheDir + rStr.substring(0, rStr.indexOf(File.separatorChar, 1));
-                    long len = file.length();
+                /*
+                 * This will get me the root directory specific to this cache item.
+                 * Example:
+                 *  cacheDir = /home/user1/.icedtea/cache
+                 *  file.getPath() = /home/user1/.icedtea/cache/0/http/www.example.com/subdir/a.jar
+                 *  rStr first becomes: /0/http/www.example.com/subdir/a.jar
+                 *  then rstr becomes: /home/user1/.icedtea/cache/0
+                 */
+                String rStr = file.getPath().substring(cacheDir.length());
+                rStr = cacheDir + rStr.substring(0, rStr.indexOf(File.separatorChar, 1));
+                long len = file.length();
 
-                    if (keep.contains(file.getPath().substring(rStr.length()))) {
-                        lruHandler.removeEntry(key);
-                        continue;
-                    }
-                    
-                    /*
-                     * we remove entries from our lru if any of the following condition is met.
-                     * Conditions:
-                     *  - delete: file has been marked for deletion.
-                     *  - !file.isFile(): if someone tampered with the directory, file doesn't exist.
-                     *  - maxSize >= 0 && curSize + len > maxSize: If a limit was set and the new size
-                     *  on disk would exceed the maximum size.
-                     */
-                    if (delete || !file.isFile() || (maxSize >= 0 && curSize + len > maxSize)) {
-                        lruHandler.removeEntry(key);
-                        remove.add(rStr);
-                    } else {
-                        curSize += len;
-                        keep.add(file.getPath().substring(rStr.length()));
+                if (keep.contains(file.getPath().substring(rStr.length()))) {
+                    lruHandler.removeEntry(key);
+                    continue;
+                }
 
-                        for (File f : file.getParentFile().listFiles()) {
-                            if (!(f.equals(file) || f.equals(pf.getStoreFile()))){
-                                try {
-                                    FileUtils.recursiveDelete(f, f);
-                                } catch (IOException e1) {
-                                    e1.printStackTrace();
-                                }
-                            }
+                /*
+                 * we remove entries from our lru if any of the following condition is met.
+                 * Conditions:
+                 *  - delete: file has been marked for deletion.
+                 *  - !file.isFile(): if someone tampered with the directory, file doesn't exist.
+                 *  - maxSize >= 0 && curSize + len > maxSize: If a limit was set and the new size
+                 *  on disk would exceed the maximum size.
+                 */
+                if (delete || !file.isFile() || (maxSize >= 0 && curSize + len > maxSize)) {
+                    lruHandler.removeEntry(key);
+                    remove.add(rStr);
+                    continue;
+                }
+
+                curSize += len;
+                keep.add(file.getPath().substring(rStr.length()));
+
+                for (File f : file.getParentFile().listFiles()) {
+                    if (!(f.equals(file) || f.equals(pf.getStoreFile()))) {
+                        try {
+                            FileUtils.recursiveDelete(f, f);
+                        } catch (IOException e1) {
+                            e1.printStackTrace();
                         }
                     }
-                } else {
-                    lruHandler.removeEntry(key);
+
                 }
             }
             lruHandler.store();
diff -r cde6d59a2901 -r 60ef5191add3 netx/net/sourceforge/jnlp/resources/Messages.properties
--- a/netx/net/sourceforge/jnlp/resources/Messages.properties	Thu Apr 05 10:57:16 2012 -0400
+++ b/netx/net/sourceforge/jnlp/resources/Messages.properties	Tue Apr 10 19:10:43 2012 +0200
@@ -192,13 +192,8 @@
 CChooseCacheInfo=Netx needs a location for storing cache files.
 CChooseCacheDir=Cache directory
 CCannotClearCache=Can not clear cache at this time
-CFakeCache=Cache is corrupt. Disabling.
-CFakedCache=Cache is corrupt and has been disabled. It is strongly recommended that you run 'javaws -Xclearcache' and rerun your application as soon as possible.
-CStillCorupted=Cache is still corrupt, clearing it.
-CCleaningUnsuccessful=Unable to clear cache due to running javaws instance. Please try to shut down all instances of javaws, run 'javaws -Xclearcache', and rerun your jnlp file
-CClearedReloading=Cache cleared, re-loading.
-CReloadRestarting=Cache re-loaded and application re-starting. It is strongly recommended that you run 'javaws -Xclearcache' and re-run your application as soon as possible.
-CStillBroken=Unable to fix corrupt cache. Please shutdown all javaws instances, run 'javaws -Xclearcache', and re-start your application.
+CFakeCache=Cache is corrupt. Fixing.
+CFakedCache=Cache is corrupt and has been fixed. It is strongly recommended that you run 'javaws -Xclearcache' and rerun your application as soon as possible.
 
 # Security
 SFileReadAccess=The application has requested read access to {0}. Do you want to allow this action?
diff -r cde6d59a2901 -r 60ef5191add3 tests/jnlp_tests/signed/CacheReproducer/testcases/CacheReproducerTest.java
--- a/tests/jnlp_tests/signed/CacheReproducer/testcases/CacheReproducerTest.java	Thu Apr 05 10:57:16 2012 -0400
+++ b/tests/jnlp_tests/signed/CacheReproducer/testcases/CacheReproducerTest.java	Tue Apr 10 19:10:43 2012 +0200
@@ -57,7 +57,8 @@
 
     private static final ServerAccess server = new ServerAccess();
     private static final List<String> clear = Arrays.asList(new String[]{server.getJavawsLocation(), "-Xclearcache",  ServerAccess.HEADLES_OPTION});
-    private static final List<String> trusted = Arrays.asList(new String[]{"-Xtrustall", ServerAccess.HEADLES_OPTION});
+    private static final List<String> trustedVerboses = Arrays.asList(new String[]{"-Xtrustall", ServerAccess.HEADLES_OPTION,"-verbose"});
+    private static final List<String> verbosed = Arrays.asList(new String[]{"-verbose", ServerAccess.HEADLES_OPTION});
     private static final String home = System.getProperty("user.home");
     private static final String name = System.getProperty("user.name");
     private static final String tmp = System.getProperty("java.io.tmpdir");
@@ -66,10 +67,17 @@
     private static final File icedteaCacheFile = new File(icedteaCache, "recently_used");
     private static final File netxLock = new File(tmp + "/" + name + "/netx/locks/netx_running");
     private static final String lre = "LruCacheException";
+    private static final String ioobe = "IndexOutOfBoundsException";
     private static final String corruptRegex = "\\d{13}";
     private static final Pattern corruptPatern = Pattern.compile(corruptRegex);
     private static final String corruptString = "156dsf1562kd5";
 
+     String testS = "#netx file\n"
+                + "#Mon Dec 12 16:20:46 CET 2011\n"
+                + "1323703236508,0=/home/xp13/.icedtea/cache/0/http/localhost/ReadPropertiesBySignedHack.jnlp\n"
+                + "1323703243086,2=/home/xp14/.icedtea/cache/2/http/localhost/ReadProperties.jar\n"
+                + "1323703243082,1=/home/xp15/.icedtea/cache/1/http/localhost/ReadPropertiesBySignedHack.jar";
+
     @Test
     public void cacheIsWorkingTest() throws Exception {
         clearAndEvaluateCache();
@@ -131,6 +139,10 @@
         Assert.assertTrue("icedtea cache file " + icedteaCacheFile.getAbsolutePath() + " should not be empty", icedteaCacheFile.length() > 0);
     }
 
+    /**
+     * This is breaking integer numbers in first part of cache file item
+     * @throws Exception
+     */
     @Test
     public void coruptAndRunCache1() throws Exception {
         clearAndEvaluateCache();
@@ -146,9 +158,13 @@
         assertLruExceptionNOTappeared(pr2);
     }
 
+    /**
+     * This is breaking integer numbers in first part of cache file item
+     * @throws Exception
+     */
     @Test
     public void coruptAndRunCache2() throws Exception {
-         clearAndEvaluateCache();
+        clearAndEvaluateCache();
         evaluateSimpleTest1OkCache(runSimpleTest1());
         assertCacheIsNotEmpty();
         breakCache1();
@@ -164,6 +180,33 @@
         assertLruExceptionNOTappeared(pr2);
     }
 
+    /**
+     * This is breaking paths in second part of cache file item
+     * @throws Exception
+     */
+    @Test
+    public void coruptAndRunCache3() throws Exception {
+        clearAndEvaluateCache();
+        evaluateSimpleTest1OkCache(runSimpleTest1());
+        assertCacheIsNotEmpty();
+        breakCache3();
+        ProcessResult pr = runSimpleTest1();
+        assertAoobNOTappeared(pr);
+        assertLruExceptionAppeared(pr);
+        evaluateSimpleTest1OkCache(pr);
+        ProcessResult pr3 = runSimpleTest1();
+        evaluateSimpleTest1OkCache(pr3);
+        assertLruExceptionNOTappeared(pr3);
+        clearAndEvaluateCache();
+        ProcessResult pr2 = runSimpleTest1();
+        evaluateSimpleTest1OkCache(pr2);
+        assertLruExceptionNOTappeared(pr2);
+    }
+
+     private void assertAoobNOTappeared(ProcessResult pr2) {
+        Assert.assertFalse("serr should NOT contain " + ioobe, pr2.stderr.contains(ioobe));
+    }
+
     private void assertLruExceptionNOTappeared(ProcessResult pr2) {
         Assert.assertFalse("serr should NOT contain " + lre, pr2.stderr.contains(lre));
     }
@@ -174,7 +217,7 @@
 
     @Test
     public void coruptAndRunCache1Signed() throws Exception {
-         clearAndEvaluateCache();
+        clearAndEvaluateCache();
         evaluateSimpleTest1OkCache(runSimpleTest1());
         assertCacheIsNotEmpty();
         breakCache1();
@@ -189,7 +232,7 @@
 
     @Test
     public void coruptAndRunCache2Signed() throws Exception {
-         clearAndEvaluateCache();
+        clearAndEvaluateCache();
         evaluateSimpleTest1OkCache(runSimpleTest1());
         assertCacheIsNotEmpty();
         breakCache1();
@@ -217,7 +260,7 @@
                 try {
                     System.out.println("connecting deadlocktest request");
                     System.err.println("connecting deadlocktest request");
-                    ServerAccess.ProcessResult pr = server.executeJavawsHeadless(null, "/deadlocktest.jnlp");
+                    ServerAccess.ProcessResult pr = server.executeJavawsHeadless(verbosed, "/deadlocktest.jnlp");
                     System.out.println(pr.stdout);
                     System.err.println(pr.stderr);
                 } catch (Exception ex) {
@@ -236,7 +279,7 @@
     }
 
      
-    //next four tests are designed to ensure, that corupted cache wil not break already loaded cached files
+    //next four tests are designed to ensure, that corrupted cache will not break already loaded cached files
     public static final String CR1 = "CacheReproducer1";
     public static final String CR2 = "CacheReproducer2";
     public static final String CR11 = "CacheReproducer1_1";
@@ -327,14 +370,9 @@
     }
 
     @Test
-    public void assertBreakersAreWorking() {


From thomas at m3y3r.de  Tue Apr 10 12:54:00 2012
From: thomas at m3y3r.de (Thomas Meyer)
Date: Tue, 10 Apr 2012 21:54:00 +0200
Subject: RFC - Reduce loading of PropertiesFile
Message-ID: <1334087640.1431.26.camel@localhost.localdomain>

diff -r 60ef5191add3 netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java
--- a/netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java	Tue Apr 10 19:10:43 2012 +0200
+++ b/netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java	Tue Apr 10 21:49:08 2012 +0200
@@ -108,11 +108,11 @@
      * Update map for keeping track of recently used items.
      */
     public synchronized void load() {
-        cacheOrder.load();
+        boolean loaded = cacheOrder.load();
         /* 
          * clean up possibly corrupted entries
          */
-        if (checkData()) {
+        if (loaded == true && checkData()) {
             if (JNLPRuntime.isDebug()) {
                 new LruCacheException().printStackTrace();
             }
@@ -125,7 +125,7 @@
     /**
      * check content of cacheOrder and remove invalid/corrupt entries
      *
-     * @return true, if cache was coruupted and affected entry removed
+     * @return true, if cache was corrupted and affected entry removed
      */
     private boolean checkData () {
         boolean modified = false;
diff -r 60ef5191add3 netx/net/sourceforge/jnlp/util/PropertiesFile.java
--- a/netx/net/sourceforge/jnlp/util/PropertiesFile.java	Tue Apr 10 19:10:43 2012 +0200
+++ b/netx/net/sourceforge/jnlp/util/PropertiesFile.java	Tue Apr 10 21:49:08 2012 +0200
@@ -35,6 +35,9 @@
 
     /** the header string */
     String header = "netx file";
+    
+    /** time of last modification */
+    long lastStore;
 
     /** lazy loaded on getProperty */
     boolean loaded = false;
@@ -104,24 +107,32 @@
      * Ensures that the file backing these properties has been
      * loaded; call this method before calling any method defined by
      * a superclass.
+     * 
+     * @return true, if file was (re-)loaded
+     *         false, if file was still current
      */
-    public void load() {
+    public boolean load() {
         loaded = true;
 
-        InputStream s = null;
-        try {
-            if (!file.exists())
-                return;
+        if(lastStore == 0 || lastStore > 0 && file.lastModified() != lastStore) {
+            InputStream s = null;
+            try {
+                if (!file.exists())
+                    return false;
+    
+                try {
+                    s = new FileInputStream(file);
+                    load(s);
+                } finally {
+                    if (s != null) s.close();
+                }
+            } catch (IOException ex) {
+                ex.printStackTrace();
+            }
+            return true;
+        }
 
-            try {
-                s = new FileInputStream(file);
-                load(s);
-            } finally {
-                if (s != null) s.close();
-            }
-        } catch (IOException ex) {
-            ex.printStackTrace();
-        }
+        return false;
     }
 
     /**
@@ -137,6 +148,7 @@
                 file.getParentFile().mkdirs();
                 s = new FileOutputStream(file);
                 store(s, header);
+                lastStore = file.lastModified();
             } finally {
                 if (s != null) s.close();
             }




From jvanek at icedtea.classpath.org  Wed Apr 11 00:51:12 2012
From: jvanek at icedtea.classpath.org (jvanek at icedtea.classpath.org)
Date: Wed, 11 Apr 2012 07:51:12 +0000
Subject: /hg/icedtea-web: Minor changes - spaces/tabs replacements
Message-ID: <hg.c115840c1974.1334130672.8643924302249223276@icedtea.classpath.org>

changeset c115840c1974 in /hg/icedtea-web
details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=c115840c1974
author: Jiri Vanek <jvanek at redhat.com>
date: Wed Apr 11 09:51:34 2012 +0200

	Minor changes - spaces/tabs replacements


diffstat:

 ChangeLog |  51 ++++++++++++++++++++++++++-------------------------
 1 files changed, 26 insertions(+), 25 deletions(-)

diffs (82 lines):

diff -r 60ef5191add3 -r c115840c1974 ChangeLog
--- a/ChangeLog	Tue Apr 10 19:10:43 2012 +0200
+++ b/ChangeLog	Wed Apr 11 09:51:34 2012 +0200
@@ -1,25 +1,26 @@
 2012-06-04  Jiri Vanek <jvanek at redhat.com>
             Thomas Meyer <thomas at m3y3r.de>
 
-        * makefile.am: (stamps/run-netx-dist-tests.stamp) and
-                       (run-reproducers-test-code-coverage.stamp)
-        now using $(javaws) variable instead of plaintext javaws
-        * netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java: (checkData) new
-        method checking for sanity of cache entries
-        (load) now checks for data sanity after loading, and stores without
-        corrupted items if necessary
-        (Comparator.compare) for sorting lru items. Now redundant checking for
-        sanity removed
-        * netx/net/sourceforge/jnlp/cache/CacheUtil.java: (getCacheFile) don't
-        call lruHandler.store twice for new cache entries
-        (getCacheFileIfExist) removed iteration and cleaning mechanism
-        * netx/net/sourceforge/jnlp/resources/Messages.properties: modified
-        cache messages
-        * tests/jnlp_tests/signed/CacheReproducer/testcases/CacheReproducerTest.java
-        Added test for checking corrupted path in entry and all tests adapted for
-        exception thrown only in debug mode
-
-2012-04-04  Danesh Dadachanji  <ddadacha at redhat.com>
+	* makefile.am: (stamps/run-netx-dist-tests.stamp) and
+	               (run-reproducers-test-code-coverage.stamp)
+	now using $(javaws) variable instead of plaintext javaws
+	* netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java: (checkData) new
+	method checking for sanity of cache entries
+	(load) now checks for data sanity after loading, and stores without
+	corrupted items if necessary
+	(Comparator.compare) for sorting lru items. Now redundant checking for
+	sanity removed
+	* netx/net/sourceforge/jnlp/cache/CacheUtil.java: (getCacheFile) don't
+	call lruHandler.store twice for new cache entries
+	(getCacheFileIfExist) removed iteration and cleaning mechanism
+	* netx/net/sourceforge/jnlp/resources/Messages.properties: modified
+	cache messages
+	* tests/jnlp_tests/signed/CacheReproducer/testcases/CacheReproducerTest.java
+	Added test for checking corrupted path in entry and all tests adapted for
+	exception thrown only in debug mode
+
+2012-04-04  Danesh Dadachanji <ddadacha at redhat.com>
+
 	Change the name of JarSigner to JarCertVerifier to make it more
 	relevant to the purpose of the file.
 	* netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java
@@ -133,10 +134,10 @@
 
 2012-04-03  Jiri Vanek <jvanek at redhat.com>
 
-    Tests virtual server thread marked as daemon by default
-    * tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java:
-    All (ServerLauncher) instances returned by methods were marked as daemon
-    by default. Possibility to change and api were kept. 
+	Tests virtual server thread marked as daemon by default
+	* tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java:
+	All (ServerLauncher) instances returned by methods were marked as daemon
+	by default. Possibility to change and api were kept. 
 
 2012-03-30  Danesh Dadachanji  <ddadacha at redhat.com>
 
@@ -707,7 +708,7 @@
 	* tests/jnlp_tests/signed/MissingJar/testcases/MissingJarTest.java
 	testing file of reproducer, launchiing above four jnlp files, each in individual test
 
-2011-10-17  Jiri Vanek <jvanek at redhat.com>   
+2011-10-17  Jiri Vanek <jvanek at redhat.com>
 
 	PR564: NetX depends on sun.misc.BASE64Encoder
 	* configure.ac: removed IT564 comment, removed check for sun.misc.BASE64Encoder
@@ -831,7 +832,7 @@
 	testcase for this reproducer 
 
 2011-09-22  Jiri Vanek <jvanek at redhat.com>
-    
+
 	* tests/jnlp_tests/signed/ReadPropertiesSigned/resources/ReadPropertiesSigned1.jnlp:
 	* tests/jnlp_tests/signed/ReadPropertiesSigned/resources/ReadPropertiesSigned2.jnlp:
 	* tests/jnlp_tests/signed/ReadPropertiesSigned/testcases/ReadPropertiesSignedTest.java:


From jvanek at icedtea.classpath.org  Wed Apr 11 01:23:17 2012
From: jvanek at icedtea.classpath.org (jvanek at icedtea.classpath.org)
Date: Wed, 11 Apr 2012 08:23:17 +0000
Subject: /hg/icedtea-web: Added and used java arguments (now Xmx2G) for e...
Message-ID: <hg.17f9e4e1ac6d.1334132597.8643924302249223276@icedtea.classpath.org>

changeset 17f9e4e1ac6d in /hg/icedtea-web
details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=17f9e4e1ac6d
author: Jiri Vanek <jvanek at redhat.com>
date: Wed Apr 11 10:19:17 2012 +0200

	Added and used java arguments (now Xmx2G) for emma runs.


diffstat:

 ChangeLog   |   8 ++++++++
 Makefile.am |  12 +++++++-----
 2 files changed, 15 insertions(+), 5 deletions(-)

diffs (70 lines):

diff -r c115840c1974 -r 17f9e4e1ac6d ChangeLog
--- a/ChangeLog	Wed Apr 11 09:51:34 2012 +0200
+++ b/ChangeLog	Wed Apr 11 10:19:17 2012 +0200
@@ -1,3 +1,11 @@
+2012-04-11  Jiri Vanek  <jvanek at redhat.com>
+
+	* Makefile.am: EMMA_JAVA_ARGS, new variable for adjusting emma runs. 
+	Currently set to -Xmx2G.
+	(stamps/run-unit-test-code-coverage.stamp),
+	(stamps/run-reproducers-test-code-coverage.stamp),
+	(run-test-code-coverage): Use EMMA_JAVA_ARGS in theirs emma runs.
+
 2012-06-04  Jiri Vanek <jvanek at redhat.com>
             Thomas Meyer <thomas at m3y3r.de>
 
diff -r c115840c1974 -r 17f9e4e1ac6d Makefile.am
--- a/Makefile.am	Wed Apr 11 09:51:34 2012 +0200
+++ b/Makefile.am	Wed Apr 11 10:19:17 2012 +0200
@@ -27,6 +27,7 @@
 JUNIT_RUNNER_JAR=$(abs_top_builddir)/junit-runner.jar
 UNIT_CLASS_NAMES = $(abs_top_builddir)/unit_class_names
 REPRODUCERS_CLASS_NAMES = $(abs_top_builddir)/reproducers_class_names
+EMMA_JAVA_ARGS=-Xmx2G
 META_MANIFEST = META-INF/MANIFEST.MF
 
 # Build directories
@@ -631,7 +632,7 @@
 	mv $(NETX_UNIT_TEST_DIR)/tests-output.xml  $(NETX_UNIT_TEST_DIR)/tests-output.xml_noEmma ; \
 	cd $(NETX_UNIT_TEST_DIR) ; \
 	class_names=`cat $(UNIT_CLASS_NAMES)` ; \
-	$(BOOT_DIR)/bin/java -Xbootclasspath:$(RUNTIME) -cp $(EMMA_JAR) -Demma.report.html.out.encoding=UTF-8 emmarun \
+	$(BOOT_DIR)/bin/java $(EMMA_JAVA_ARGS) -Xbootclasspath:$(RUNTIME) -cp $(EMMA_JAR) -Demma.report.html.out.encoding=UTF-8 emmarun \
 	 -Dreport.html.out.encoding=UTF-8 \
 	 -raw \
 	 -sp $(NETX_SRCDIR) \
@@ -696,6 +697,7 @@
 	cd $(JNLP_TESTS_ENGINE_DIR) ; \
 	class_names=`cat $(REPRODUCERS_CLASS_NAMES)` ; \
 	$(BOOT_DIR)/bin/java  \
+	 $(EMMA_JAVA_ARGS) \
 	 -Dtest.server.dir=$(JNLP_TESTS_SERVER_DEPLOYDIR) \
 	 -Djavaws.build.bin=$(DESTDIR)$(bindir)/$(javaws) \
 	 -Xbootclasspath:$(RUNTIME) -cp $(EMMA_JAR) emmarun  \
@@ -712,11 +714,11 @@
 	   CommandLine $$class_names ; \
 	mv $(JNLP_TESTS_ENGINE_DIR)/coverage.ec $(JNLP_TESTS_ENGINE_DIR)/coverageX.ec ; \
 	mv $(JNLP_TESTS_ENGINE_DIR)/coverage.es $(JNLP_TESTS_ENGINE_DIR)/coverageX.es ; \
-	$(BOOT_DIR)/bin/java -cp $(EMMA_JAR) emma merge \
+	$(BOOT_DIR)/bin/java $(EMMA_JAVA_ARGS) -cp $(EMMA_JAR) emma merge \
 	  -in $(TESTS_DIR)/coverage.em \
 	  -in $(JNLP_TESTS_ENGINE_DIR)/coverageX.ec \
 	  -in $(JNLP_TESTS_ENGINE_DIR)/coverageX.es ; \
-	$(BOOT_DIR)/bin/java -cp $(EMMA_JAR)  -Demma.report.html.out.encoding=UTF-8 emma report \
+	$(BOOT_DIR)/bin/java $(EMMA_JAVA_ARGS) -cp $(EMMA_JAR)  -Demma.report.html.out.encoding=UTF-8 emma report \
 	  -Dreport.html.out.encoding=UTF-8 \
 	  -in $(JNLP_TESTS_ENGINE_DIR)/coverage.es  \
 	  -sp $(NETX_SRCDIR) \
@@ -756,10 +758,10 @@
 	    k=$$((k+1)) ; \
 	  done ; \
 	done ; \
-	$(BOOT_DIR)/bin/java -cp $(EMMA_JAR) emma merge \
+	$(BOOT_DIR)/bin/java $(EMMA_JAVA_ARGS) -cp $(EMMA_JAR) emma merge \
 	 -in $(NETX_UNIT_TEST_DIR)/coverage.es \
 	 -in $(JNLP_TESTS_ENGINE_DIR)/coverage.es ; \
-	$(BOOT_DIR)/bin/java -cp $(EMMA_JAR)  -Demma.report.html.out.encoding=UTF-8 emma report \
+	$(BOOT_DIR)/bin/java $(EMMA_JAVA_ARGS) -cp $(EMMA_JAR)  -Demma.report.html.out.encoding=UTF-8 emma report \
 	 -Dreport.html.out.encoding=UTF-8 \
 	 -in $(TESTS_DIR)/coverage.es \
 	 -in $(TESTS_DIR)/coverage.em \


From bugzilla-daemon at icedtea.classpath.org  Wed Apr 11 02:09:17 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Wed, 11 Apr 2012 09:09:17 +0000
Subject: [Bug 917] New: plugin crashes when calling javascript function
Message-ID: <bug-917-30@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=917

             Bug #: 917
           Summary: plugin crashes when calling javascript function
    Classification: Unclassified
           Product: IcedTea-Web
           Version: 1.2
          Platform: x86_64
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Plugin
        AssignedTo: dbhole at redhat.com
        ReportedBy: doko at ubuntu.com
                CC: unassigned at icedtea.classpath.org


reported for icedtea-web-1.2, forwarded from
https://launchpad.net/bugs/755036

Working with chrome on ubuntu, have a basic java applet and javascript
interaction. The javascript to java goes fine, but when I try having the java
fire a javascript method, the chrome java plugin crashes. This all works fine
in Fire Fox.

The Error:

    The following plug-in has crashed: icedTea NPR Web Broweser Plugin (using
IcedTea6 1.9.7 (6b20-1.9.7-0ubuntu1~10.04.1))

The HTML:

    <object height='300' id='thisappletawesome'
name='thisappletawesome'type='application/x-java-applet' width='550'>
        <param name='classid' value='java:JSHelloWorld.class'>
        <param name='codebase' value='/java/'>
    </object>

The Javascript:

    function updateWebPage(){
        alert("java is touching me");
        document.thisappletawesome.setText("hihihi")
    }

The Java:

    import java.applet.*;
    import java.awt.*;
    import netscape.javascript.*;
    import javax.swing.*;

    public class JSHelloWorld extends JApplet {
    JTextArea txt = new JTextArea(100,100);

    public void init(){
     JSObject jso = JSObject.getWindow(this);
     try {
      jso.call("updateWebPage", new String[] {"Hihi"});
        }
        catch (Exception ex) {
           ex.printStackTrace();
        }
    }

    public JSHelloWorld() {
        txt.setText("Hello World");
        getContentPane().add(txt);
    }

    public void setText(String s)
    {
        txt.setText(s);
    }
}

-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


From bugzilla-daemon at icedtea.classpath.org  Wed Apr 11 02:21:57 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Wed, 11 Apr 2012 09:21:57 +0000
Subject: [Bug 918] New: java applet windows uses a low resulution black/white
	icon
Message-ID: <bug-918-30@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=918

             Bug #: 918
           Summary: java applet windows uses a low resulution black/white
                    icon
    Classification: Unclassified
           Product: IcedTea-Web
           Version: 1.2
          Platform: x86_64
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: NetX (javaws)
        AssignedTo: omajid at redhat.com
        ReportedBy: doko at ubuntu.com
                CC: unassigned at icedtea.classpath.org


forwarded from https://bugs.launchpad.net/bugs/863228, the suggestion is not to
ship the low resolution icon, so that the default gnome file is used.

if the browser-java-applets starts a new window it will hava the java-netx
icon, wich is a 16x16only, black and whits "NX"-Text symbol.
you can find it in the file '''/usr/share/icedtea-web/netx.jar''' > net >
sourceforge > jnlp >resources > netx-icon.png
This is a very bad behavios because
1. its ugly
2. a user will not bring "nx" in some relationship with a javaapplet
3. its only 16x16
4. it should use the icon from
/usr/share/applications/icedtea-netx-javaws.desktop

the solution is just simple:
delete the file netx-icon.png from '''/usr/share/icedtea-web/netx.jar''' > net
> sourceforge > jnlp >resources. then it will use the icon wich is given in the
/usr/share/applications/icedtea-netx-javaws.desktop file

-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


From jvanek at redhat.com  Wed Apr 11 02:34:20 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Wed, 11 Apr 2012 11:34:20 +0200
Subject: [rfc][icedtea-web] signed applets test
Message-ID: <4F85501C.1080003@redhat.com>

Hi!

This is implementation of what we have agreed for signed applets - add(and remove) certificate to 
~/.icedtea/security/trusted.certs, launch applet signed by this cert in explorer and read stdout/in 
as we are doing for applet tests right now.

There is question how to deal with -Xtrustall which is now useless when there is trusted certificate 
(all signed reproducers are right now signed with same cert, and when more to much reproducers will 
need to much different certificates this will need re-factoring probably too).

After  this change is in, the PR905 reproducer have sense to go in too.

changelog:

2012-04-11  Jiri Vanek  <jvanek at redhat.com>

	Allowed signed appletes in automatic reproducers tests
	* tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.html:
	html file for lunching signed applet. Its stile is different from the one for
	calling unsigned applets.
	* tests/jnlp_tests/signed/AppletTestSigned/resources/bd.css: style of signed
	applets page
	* tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.jnlp:
	jnlp fiel for lunched signed applet
	* tests/jnlp_tests/signed/AppletTestSigned/srcs/AppletTestSigned.java
	body of signed applet
	* tests/jnlp_tests/signed/AppletTestSigned/testcases/AppletTestSignedTests.java:
	(AppletTestSignedTest) testing method to launch signed applet in javaws
	(AppletTestSignedFirefoxTest) testing method to launch signed applet in
	browser
	* Makefile.am: KEYSTORE_PASS, EXPORTED_CERT, TEST_CERT_ALIAS, PUBLIC_KEYSTORE
	PUBLIC_PASS: new globnal variables holding keystores credentials
	(clean-local) clean-bootstrap-directory moved to be last one, as keytool
	is necessary for removing certificate
	(EXPORTED_CERT): new target exporting certificate from testing keystore
	(stamps/netx-dist-tests-import-cert-to-public) new target to import
	certificate to PUBLIC_KEYSTORE
	(netx-dist-tests-remove-cert-from-public) new target removing testing
	certificate from PUBLIC_KEYSTORE
	(clean-netx-dist-tests) now depends on netx-dist-tests-remove-cert-from-public
	and is removing EXPORTED_CERT file
	
	

Best regards, J
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signedApplets.diff
Type: text/x-patch
Size: 18782 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120411/15396ebe/signedApplets.diff 

From bugzilla-daemon at icedtea.classpath.org  Wed Apr 11 02:33:20 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Wed, 11 Apr 2012 09:33:20 +0000
Subject: [Bug 919] New: applet doesn't finish loading
Message-ID: <bug-919-30@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=919

             Bug #: 919
           Summary: applet doesn't finish loading
    Classification: Unclassified
           Product: IcedTea-Web
           Version: 1.2
          Platform: x86_64
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Plugin
        AssignedTo: dbhole at redhat.com
        ReportedBy: doko at ubuntu.com
                CC: unassigned at icedtea.classpath.org


forwarded from https://launchpad.net/bugs/927065, seen with 1.2

https://www.netbank.nordea.dk/netbank/index.jsp doesn't finish loading


this applet doesn't initialize:
https://ebanking.danskebank.dk/html/index.html?site=DBNBEN&secsystem=DI

-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


From bugzilla-daemon at icedtea.classpath.org  Wed Apr 11 02:50:06 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Wed, 11 Apr 2012 09:50:06 +0000
Subject: [Bug 920] New: applets don't load in browser but work in appletviewer
Message-ID: <bug-920-30@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=920

             Bug #: 920
           Summary: applets don't load in browser but work in appletviewer
    Classification: Unclassified
           Product: IcedTea-Web
           Version: 1.2
          Platform: x86_64
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Plugin
        AssignedTo: dbhole at redhat.com
        ReportedBy: doko at ubuntu.com
                CC: unassigned at icedtea.classpath.org


forwarded from https://launchpad.net/883598, reproduced with 1.2

"I'm having trouble viewing certain Java applets from Firefox. The applets work
fine if the url is fed into appletviewer (provided by openjdk-6-jdk), but
running them in the browser gives various errors related to class loading.
Examples of such errors would be either a class cast exception or class loader
magic number error.

Problematic applets:
http://games.yahoo.com/console/tx
https://www.thirdfederal.com/Calculators/fixedmortgagecalculator.aspx
"

-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


From xranby at icedtea.classpath.org  Wed Apr 11 03:02:52 2012
From: xranby at icedtea.classpath.org (xranby at icedtea.classpath.org)
Date: Wed, 11 Apr 2012 10:02:52 +0000
Subject: /hg/release/icedtea7-forest-2.1/hotspot: Use unified syntax for ...
Message-ID: <hg.26f5d8596931.1334138572.-6171416105482022170@icedtea.classpath.org>

changeset 26f5d8596931 in /hg/release/icedtea7-forest-2.1/hotspot
details: http://icedtea.classpath.org/hg/release/icedtea7-forest-2.1/hotspot?cmd=changeset;node=26f5d8596931
author: aph
date: Fri Mar 16 08:36:04 2012 -0400

	Use unified syntax for thumb code.
	2012-03-16  Andrew Haley  <aph at redhat.com>

	        * hotspot/src/cpu/zero/vm/arm_cas.S: Use unified syntax
	        for thumb code.


diffstat:

 src/cpu/zero/vm/arm_cas.S |  1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diffs (11 lines):

diff -r 30c4dc24823a -r 26f5d8596931 src/cpu/zero/vm/arm_cas.S
--- a/src/cpu/zero/vm/arm_cas.S	Thu Mar 15 09:07:01 2012 -0400
+++ b/src/cpu/zero/vm/arm_cas.S	Fri Mar 16 08:36:04 2012 -0400
@@ -6,6 +6,7 @@
 	.pushsection .text
 	.global arm_val_compare_and_swap_long
 #ifdef __thumb__
+	.syntax	unified
 	.thumb_func
 #endif
 	.type arm_val_compare_and_swap_long, %function


From xerxes at zafena.se  Wed Apr 11 05:40:17 2012
From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=)
Date: Wed, 11 Apr 2012 14:40:17 +0200
Subject: RFC: icedtea7-2.1: Bump Hotspot to bring in unified syntax for thumb
	code and support glib >= 2.32.
Message-ID: <4F857BB1.40109@zafena.se>

Hi team,
I would like to commit two changes to the icedtea7-2.1 release branch.

1. a fix for a missing -lgthread-2.0 to gcc that cause the following error:
src/solaris/native/sun/awt/gtk2_interface.c:218: undefined reference to `g_thread_init'
http://icedtea.classpath.org/hg/icedtea7/raw-rev/ab3f4766a208

2. and a bump of the hotspot changeset to bring in;
http://icedtea.classpath.org/hg/release/icedtea7-forest-2.1/hotspot/rev/26f5d8596931
this part was missing in the recent arm_port import from icedtea6 into icedtea7. It fixes the following compile error on thumb2 arm systems:
/build/buildd/openjdk-7-7~u3-2.1.1~pre1/build/openjdk-boot/hotspot/src/cpu/zero/vm/arm_cas.S: Assembler messages:
/build/buildd/openjdk-7-7~u3-2.1.1~pre1/build/openjdk-boot/hotspot/src/cpu/zero/vm/arm_cas.S:13: Error: lo register required -- `stmfd sp!,{r4,r5,r6,r7}'
/build/buildd/openjdk-7-7~u3-2.1.1~pre1/build/openjdk-boot/hotspot/src/cpu/zero/vm/arm_cas.S:19: Error: Thumb does not support conditional execution
/build/buildd/openjdk-7-7~u3-2.1.1~pre1/build/openjdk-boot/hotspot/src/cpu/zero/vm/arm_cas.S:20: Error: incorrect condition in IT block -- `bne 1f'
/build/buildd/openjdk-7-7~u3-2.1.1~pre1/build/openjdk-boot/hotspot/src/cpu/zero/vm/arm_cas.S:27: Error: lo register required -- `ldmfd sp!,{r4,r5,r6,r7}'
make[8]: *** [arm_cas.o] Error 1

Cheers
Xerxes


diff -r 8ea793eccbd1 ChangeLog
--- a/ChangeLog	Tue Apr 03 01:16:08 2012 +0100
+++ b/ChangeLog	Wed Apr 11 15:34:11 2012 +0200
@@ -1,3 +1,15 @@
+2012-04-11  Xerxes R?nby  <xerxes at zafena.se>
+
+	* Makefile.am:
+	(HOTSPOT_CHANGESET): Sync to HEAD.
+	(HOTSPOT_SHA256SUM): Likewise.
+
+2012-04-06  Andrew John Hughes  <ahughes at redhat.com>
+
+	* acinclude.m4:
+	(IT_CHECK_FOR_GTK): Work with glib >= 2.32
+	by explicitly asking for gthread.
+
 2012-03-29  Andrew John Hughes  <ahughes at redhat.com>

          * Makefile.am:
diff -r 8ea793eccbd1 Makefile.am
--- a/Makefile.am	Tue Apr 03 01:16:08 2012 +0100
+++ b/Makefile.am	Wed Apr 11 15:34:11 2012 +0200
@@ -5,7 +5,7 @@
 COMBINED_VERSION = $(JDK_UPDATE_VERSION)-$(OPENJDK_VERSION)

 CORBA_CHANGESET = 5617f6c5cc94
-HOTSPOT_CHANGESET = 30c4dc24823a
+HOTSPOT_CHANGESET = 26f5d8596931
 JAXP_CHANGESET = 1cf75c0e2c96
 JAXWS_CHANGESET = 7edfbfe974f2
 JDK_CHANGESET = 2d8ad70a2243
@@ -13,7 +13,7 @@
 OPENJDK_CHANGESET = 22cc03983e20

 CORBA_SHA256SUM = 963915483530f311ff313635f79ed11ea7ce5a1c0dbee5d1acb1994132857fa3
-HOTSPOT_SHA256SUM = 1a9290c85a280a21256c96e98f2461a88481d63fc4792725845caaeb155fa623
+HOTSPOT_SHA256SUM = 3bf8b0a93105a0a6dbc657eaf7c95b5dd9a8dc478544e75b9e90571632f6a522
 JAXP_SHA256SUM = 8ce48c704f38285207ee6dc56c45b2d214083b4d4d36be02901401b594ce701e
 JAXWS_SHA256SUM = 823ca6b8fd780bf1b1565a90cfc8ec6f0ee422a5d25ffb20b1ce0272dc4955aa
 JDK_SHA256SUM = a3f1748212086feb3351772c1bc3eb6a2918fac474a37bec219d97b668676f40
diff -r 8ea793eccbd1 acinclude.m4
--- a/acinclude.m4	Tue Apr 03 01:16:08 2012 +0100
+++ b/acinclude.m4	Wed Apr 11 15:34:11 2012 +0200
@@ -2011,7 +2011,7 @@
   AC_MSG_RESULT(${ENABLE_SYSTEM_GTK})
   if test x"${ENABLE_SYSTEM_GTK}" = "xyes"; then
     dnl Check for Gtk+ headers and libraries.
-    PKG_CHECK_MODULES(GTK, gtk+-2.0,[GTK_FOUND=yes],[GTK_FOUND=no])
+    PKG_CHECK_MODULES(GTK, gtk+-2.0 gthread-2.0,[GTK_FOUND=yes],[GTK_FOUND=no])
     if test "x${GTK_FOUND}" = xno
     then
       AC_MSG_ERROR([Could not find Gtk+; install Gtk+ or build with --disable-system-gtk to use the in-tree headers.])


From adinn at redhat.com  Wed Apr 11 05:16:22 2012
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 11 Apr 2012 13:16:22 +0100
Subject: ARM: JSR 292 MethodHandle support
In-Reply-To: <4F79A4CD.40408@redhat.com>
References: <4F79A4CD.40408@redhat.com>
Message-ID: <4F857616.8050203@redhat.com>

Hi,

Better late than never, included below is a review of Andrew's patch.

regards,


Andrew Dinn
-----------

Summary:
--------

  * A code walkthrough generated a few minor comments and 1 edit but 
found no serious problems.

  * Building the patched release encountered 1 build problem in the 
patched code which was subsequently resolved by Andrew. There were a 
couple of other patches required to the latest icedtea7-forest-2.1 build 
system.

  * The patched build successfully executes some of the invokedynamic 
test code but throws a lot of 'not yet implemented' errors.

Detailed comments:
------------------

Code Walkthrough
----------------

  * cppInterpreter_arm.S line 3141 (of patched file)

     ldr     r0, [r8, #ISTATE_THREAD]

should be

     ldr     r0, [istate, #ISTATE_THREAD]

  * cppInterpreter_arm.S line 3099 (of patched file)

     bl      _ZN14CppInterpreter21process_method_handleEP7oopDescP6Thread

this is not strictly an API method of CppInterpreter but it is unlikely 
to disappear so it is probably ok to co-opt it

  * cppInterpreter_arm.S line 3155 (of patched file)

     // Common code for fast_aldc_w and fast_aldc_w

this should read

     // Common code for fast_aldc and fast_aldc_w

  * thumb2.cpp line 6587 (of patched file)

the JITted code for invokedynamic just calls out to the interpreter

   Thumb2_Exit(jinfo, H_EXIT_TO_INTERPRETER, bci, stackdepth)

This means the VM interprets the current method from this point on. so 
it might be worth revising this later to do the work in JITted code and 
allow JIT execution to continue.

Build Problems
--------------

  * cppInterpreter_arm.S line 3087 (of patched file)

This line was originally provided as

     bl     _ZN25java_lang_invoke_CallSite22target_offset_in_bytesEv

However, this failed to compile -- I think because 
java_lang_invoke_CallSite::target_offset_in_bytes() is defined inline in 
a header file and the compiler did not generate an out of line callable 
function.

This was fixed by Andrew Haley by defining a wrapper function 
Helper_target_offset_in_bytes in asm_helper.c and calling the wrapper 
from the asm

    bl      Helper_target_offset_in_bytes


  * jdk/make/common/shared/Compiler-gcc.gmk

This was setting

   SHARED_LIBRARY_FLAG = -shared -mimpure-text

but the second flag is invalid for arm (or indeed anything other than 
SPARC according to the gcc manual). So it needs to be removed.

  * jdk/make/jdk_generic_profile.sh

This script needs an entry for arm in the case switch at line 283 i.e.

    # ZERO_ENDIANNESS is the endianness of the processor
    case "${ZERO_LIBARCH}" in
-    i386|amd64|ia64)
+    i386|amd64|ia64|arm)

and also another case at line 310 i.e.

      s390)
        ZERO_ARCHFLAG="-m31"
        ;;
+    arm)
+      ZERO_ARCHFLAG="-D_LITTLE_ENDIAN"
+      ;;
      *)


From aph at redhat.com  Wed Apr 11 06:13:50 2012
From: aph at redhat.com (Andrew Haley)
Date: Wed, 11 Apr 2012 14:13:50 +0100
Subject: ARM: JSR 292 MethodHandle support
In-Reply-To: <4F857616.8050203@redhat.com>
References: <4F79A4CD.40408@redhat.com> <4F857616.8050203@redhat.com>
Message-ID: <4F85838E.5010006@redhat.com>

On 04/11/2012 01:16 PM, Andrew Dinn wrote:

>   * cppInterpreter_arm.S line 3141 (of patched file)
> 
>      ldr     r0, [r8, #ISTATE_THREAD]
> 
> should be
> 
>      ldr     r0, [istate, #ISTATE_THREAD]

OK.

>   * cppInterpreter_arm.S line 3099 (of patched file)
> 
>      bl      _ZN14CppInterpreter21process_method_handleEP7oopDescP6Thread
> 
> this is not strictly an API method of CppInterpreter but it is unlikely 
> to disappear so it is probably ok to co-opt it

CppInterpreter_arm.S is really part of CppInterpreter; it's not
unreasonable to use internal methods.

>   * cppInterpreter_arm.S line 3155 (of patched file)
> 
>      // Common code for fast_aldc_w and fast_aldc_w
> 
> this should read
> 
>      // Common code for fast_aldc and fast_aldc_w

OK.

>   * thumb2.cpp line 6587 (of patched file)
> 
> the JITted code for invokedynamic just calls out to the interpreter
> 
>    Thumb2_Exit(jinfo, H_EXIT_TO_INTERPRETER, bci, stackdepth)
> 
> This means the VM interprets the current method from this point on. so 
> it might be worth revising this later to do the work in JITted code and 
> allow JIT execution to continue.

Definitely.

> Build Problems
> --------------
> 
>   * cppInterpreter_arm.S line 3087 (of patched file)
> 
> This line was originally provided as
> 
>      bl     _ZN25java_lang_invoke_CallSite22target_offset_in_bytesEv
> 
> However, this failed to compile -- I think because 
> java_lang_invoke_CallSite::target_offset_in_bytes() is defined inline in 
> a header file and the compiler did not generate an out of line callable 
> function.
> 
> This was fixed by Andrew Haley by defining a wrapper function 
> Helper_target_offset_in_bytes in asm_helper.c and calling the wrapper 
> from the asm
> 
>     bl      Helper_target_offset_in_bytes

OK, applied.

None of the other problems are anything to do with this patch, so
we should handle them separately.

Andrew.


From aph at icedtea.classpath.org  Wed Apr 11 06:31:32 2012
From: aph at icedtea.classpath.org (aph at icedtea.classpath.org)
Date: Wed, 11 Apr 2012 13:31:32 +0000
Subject: /hg/release/icedtea7-forest-2.1/hotspot: 8 new changesets
Message-ID: <hg.abb2e68c5b75.1334151092.-6171416105482022170@icedtea.classpath.org>

changeset abb2e68c5b75 in /hg/release/icedtea7-forest-2.1/hotspot
details: http://icedtea.classpath.org/hg/release/icedtea7-forest-2.1/hotspot?cmd=changeset;node=abb2e68c5b75
author: aph
date: Tue Mar 27 09:40:08 2012 -0400

	ARM: First cut of invokedynamic


changeset e93a90a2e36b in /hg/release/icedtea7-forest-2.1/hotspot
details: http://icedtea.classpath.org/hg/release/icedtea7-forest-2.1/hotspot?cmd=changeset;node=e93a90a2e36b
author: aph
date: Fri Mar 30 11:53:01 2012 -0400

	invokedynamic and aldc for JIT


changeset 1f74c188b8c9 in /hg/release/icedtea7-forest-2.1/hotspot
details: http://icedtea.classpath.org/hg/release/icedtea7-forest-2.1/hotspot?cmd=changeset;node=1f74c188b8c9
author: aph
date: Fri Mar 30 13:34:30 2012 -0400

	ARM: JIT-compilation of ldc methodHandle


changeset 5d0f06195a3c in /hg/release/icedtea7-forest-2.1/hotspot
details: http://icedtea.classpath.org/hg/release/icedtea7-forest-2.1/hotspot?cmd=changeset;node=5d0f06195a3c
author: aph
date: Mon Apr 02 06:09:48 2012 -0400

	Revert change to -O0


changeset b903326db836 in /hg/release/icedtea7-forest-2.1/hotspot
details: http://icedtea.classpath.org/hg/release/icedtea7-forest-2.1/hotspot?cmd=changeset;node=b903326db836
author: aph
date: Tue Apr 10 12:20:08 2012 -0400

	Use unified syntax for thumb code.


changeset ef453193835c in /hg/release/icedtea7-forest-2.1/hotspot
details: http://icedtea.classpath.org/hg/release/icedtea7-forest-2.1/hotspot?cmd=changeset;node=ef453193835c
author: aph
date: Tue Apr 10 12:22:01 2012 -0400

	Tidy up, minor comment changes.


changeset 0d46eb9c099f in /hg/release/icedtea7-forest-2.1/hotspot
details: http://icedtea.classpath.org/hg/release/icedtea7-forest-2.1/hotspot?cmd=changeset;node=0d46eb9c099f
author: aph
date: Wed Apr 11 09:22:39 2012 -0400

	Minor review cleanups.


changeset a5d04cb60a5c in /hg/release/icedtea7-forest-2.1/hotspot
details: http://icedtea.classpath.org/hg/release/icedtea7-forest-2.1/hotspot?cmd=changeset;node=a5d04cb60a5c
author: aph
date: Wed Apr 11 09:24:03 2012 -0400

	merge


diffstat:

 src/cpu/zero/vm/arm_cas.S            |    1 +
 src/cpu/zero/vm/asm_helper.cpp       |    5 +
 src/cpu/zero/vm/bytecodes_arm.def    |    3 +
 src/cpu/zero/vm/cppInterpreter_arm.S |  156 +++++++++++++++++++++++++++++++++-
 src/cpu/zero/vm/thumb2.cpp           |   76 +++++++++++++++-
 5 files changed, 229 insertions(+), 12 deletions(-)

diffs (403 lines):

diff -r 30c4dc24823a -r a5d04cb60a5c src/cpu/zero/vm/arm_cas.S
--- a/src/cpu/zero/vm/arm_cas.S	Thu Mar 15 09:07:01 2012 -0400
+++ b/src/cpu/zero/vm/arm_cas.S	Wed Apr 11 09:24:03 2012 -0400
@@ -6,6 +6,7 @@
 	.pushsection .text
 	.global arm_val_compare_and_swap_long
 #ifdef __thumb__
+	.syntax	unified
 	.thumb_func
 #endif
 	.type arm_val_compare_and_swap_long, %function
diff -r 30c4dc24823a -r a5d04cb60a5c src/cpu/zero/vm/asm_helper.cpp
--- a/src/cpu/zero/vm/asm_helper.cpp	Thu Mar 15 09:07:01 2012 -0400
+++ b/src/cpu/zero/vm/asm_helper.cpp	Wed Apr 11 09:24:03 2012 -0400
@@ -373,6 +373,11 @@
 	       err_msg(msg, opcode, name));
 }
 
+extern "C" int Helper_target_offset_in_bytes()
+{
+  return java_lang_invoke_CallSite::target_offset_in_bytes();
+}
+
 #endif // STATIC_OFFSETS
 
 #ifdef STATIC_OFFSETS
diff -r 30c4dc24823a -r a5d04cb60a5c src/cpu/zero/vm/bytecodes_arm.def
--- a/src/cpu/zero/vm/bytecodes_arm.def	Thu Mar 15 09:07:01 2012 -0400
+++ b/src/cpu/zero/vm/bytecodes_arm.def	Wed Apr 11 09:24:03 2012 -0400
@@ -219,6 +219,7 @@
 invokespecial        = 0xb7, 3
 invokestatic         = 0xb8, 3
 invokeinterface      = 0xb9, 0
+invokedynamic        = 0xba, 0
 new                  = 0xbb, 3
 newarray             = 0xbc, 2
 anewarray            = 0xbd, 3
@@ -269,6 +270,8 @@
 iload_iload	= 0xe3, 4
 iload_iload_N	= 0xe4, 3
 
+fast_aldc	= 0xe5, 2
+fast_aldc_w	= 0xe6, 3
 @return_register_finalizer = 0xe7, 1
 
 iload_0_iconst_N        = 0xe9, 2
diff -r 30c4dc24823a -r a5d04cb60a5c src/cpu/zero/vm/cppInterpreter_arm.S
--- a/src/cpu/zero/vm/cppInterpreter_arm.S	Thu Mar 15 09:07:01 2012 -0400
+++ b/src/cpu/zero/vm/cppInterpreter_arm.S	Wed Apr 11 09:24:03 2012 -0400
@@ -802,7 +802,7 @@
         .word   empty_entry                     // empty method (code: _return)
         .word   accessor_entry                  // accessor method (code: _aload_0, _getfield, _(a|i)return)
         .word   normal_entry                    // abstract method (throws an AbstractMethodException)
-        .word   vm_fatal_error                  // java.dyn.MethodHandles::invoke
+        .word   method_handle_entry             // java.lang.invoke.MethodHandles::invoke
         .word   normal_entry                    // implementation of java.lang.Math.sin   (x)
         .word   normal_entry                    // implementation of java.lang.Math.cos   (x)
         .word   normal_entry                    // implementation of java.lang.Math.tan   (x)
@@ -988,6 +988,7 @@
 			.word	.abortentry114, 1
 		FBC	.word	.abortentry117, 0
 			.word	.abortentry118, 0
+			.word	.abortentry119, 1
 	.word	0
 
 #endif
@@ -2746,6 +2747,9 @@
 	Opcode	fast_iload_N_iload_N
 #endif
 	Opcode	undefined
+	// Decache to get better diagnostic info
+	DECACHE_JPC
+	DECACHE_STACK
 	ldr	r2, [dispatch, #Bytecodes_name_Address-XXX]
 	ldrb	r3, [jpc, #0]	@ zero_extendqisi2
 	adrl	r0, bytecode_interpreter_str
@@ -2755,7 +2759,7 @@
 	adr	r2, unimplemented_opcode_msg
 	ldr	r1, =__LINE__
 	str	ip, [arm_sp, #-8]!
-	bl	Helper_report_fatal
+ 	bl	Helper_report_fatal
 	b	breakpoint
 	.ltorg
 unimplemented_opcode_msg:
@@ -3054,6 +3058,147 @@
 	ldr	tmp2, [r3, #INSTANCEKLASS_VTABLE_OFFSET]
 	b	.invokeinterface_invoke
 
+# r2 = [jpc, #1]
+	Opcode	invokedynamic
+	DECACHE_STACK
+	// Fetch index bytes from bytecode
+	ldrb	r0, [jpc, #2]
+	ldrb	r1, [jpc, #3]
+	ldrb	r3, [jpc, #4]
+	orr	r2, r2, r0, lsl #8
+	orr	r2, r2, r1, lsl #16
+	orr	r1, r2, r3, lsl #24
+	// The index is inverted, so we invert it back with MVN
+        mvn     r1, r1
+	// The pool entry is in R0
+        add     r0, constpool, r1, lsl #4
+
+	// Save the pool entry
+	stmfd	arm_sp!, {r0}
+
+	DECACHE_JPC
+	ldr     r1, [r0, #CP_OFFSET+4]  // Pointer to call site
+	// Already resolved?
+	cmp     r1, #0 
+	bleq    resolve_invokedynamic
+
+	// Get the offset from a call site to the corresponding target
+	// method handle
+	bl	Helper_target_offset_in_bytes
+	mov	lr, r0
+
+	// Restore the pool entry
+	ldmfd	arm_sp!, {r0}
+
+	ldr	r0, [r0, #CP_OFFSET+4]	// Call site
+.abortentry119:
+	ldr	r0, [r0, lr]		// Method handle
+	ldr	r1, [istate, #ISTATE_THREAD]
+
+	// Call the target method
+	bl	_ZN14CppInterpreter21process_method_handleEP7oopDescP6Thread
+
+	// Load up the interpreter registers.  Probably not necessary
+	adrl	ip, dispatch_init_adcon
+	ldm	ip, {r0, r1}
+	add	r0, r0, ip
+	add	dispatch, r1, r0
+
+	CACHE_LOCALS
+
+	ldr	ip, [istate, #ISTATE_THREAD]
+	CACHE_JPC
+	ldr	stack, [ip, #THREAD_JAVA_SP]
+	ldr	r2, [istate, #ISTATE_STACK_LIMIT]
+	sub	stack, stack, #4
+
+	// Fix up everything in the thread state to point to the
+	// current frame
+	ldr	r1, [ip, #THREAD_JAVA_SP]
+	stmfd	arm_sp!, {r1}
+	mov	r1, #0
+	str	r1, [ip, #THREAD_LAST_JAVA_SP]
+	ldr	r1, [ip, #THREAD_TOP_ZERO_FRAME]
+	add	r2, r2, #4
+	str	r2, [ip, #THREAD_JAVA_SP]
+	str	r1, [ip, #THREAD_LAST_JAVA_FP]
+	ldmfd	arm_sp!, {r1}
+	str	r1, [ip, #THREAD_LAST_JAVA_SP]
+	DISPATCH_START	5
+	// Test for an exception
+	ldr	r3, [ip, #4]
+	DISPATCH_NEXT
+	DISPATCH_NEXT
+	cmp	r3, #0
+	DISPATCH_NEXT
+	bne	invokedynamic_exception_fix
+	DISPATCH_NEXT
+	CACHE_CP
+	DISPATCH_FINISH
+
+resolve_invokedynamic:
+	stmfd	arm_sp!, {lr}
+	ldr	r0, [istate, #ISTATE_THREAD]
+	bl	_ZN18InterpreterRuntime21resolve_invokedynamicEP10JavaThread
+	ldmfd	arm_sp!, {pc}
+
+	// Handler for java.lang.invoke.MethodHandles::invoke
+	ALIGN_CODE
+method_handle_entry:
+ 	b	fast_method_handle_entry	
+	ALIGN_CODE
+fast_method_handle_entry:
+	stmfd	arm_sp!, {regset, lr}
+	bl	_ZN14CppInterpreter19method_handle_entryEP13methodOopDesciP6Thread
+	ldmia	sp!, {regset, pc}
+
+	// Common code for fast_aldc and fast_aldc_w
+# r0 = constpool cache entry
+	.macro	aldc	opc, seq_len
+	// Save the pool entry
+	stmfd	arm_sp!, {r0}
+
+	DECACHE_JPC
+	ldr     r1, [r0, #CP_OFFSET+4]  // Pointer to call site
+	// Already resolved?
+	cmp     r1, #0 
+	ldr	r0, [istate, #ISTATE_THREAD]
+	mov	r1, #\opc
+	bleq    _ZN18InterpreterRuntime11resolve_ldcEP10JavaThreadN9Bytecodes4CodeE
+
+	// Restore the pool entry
+	ldmfd	arm_sp!, {r0}
+
+	ldr     r1, [r0, #CP_OFFSET+4]  // Pointer to MethodHandle
+	PUSH	r1
+
+	// Test for an exception
+	ldr	ip, [istate, #ISTATE_THREAD]
+	ldr	r3, [ip, #4]
+	cmp	r3, #0
+	bne	handle_exception
+	
+	DISPATCH	\seq_len
+	.endm
+
+	// Handler for ldc MethodHandle
+# r2 = [jpc, #1]
+	Opcode fast_aldc
+	DECACHE_STACK
+        add     r0, constpool, r2, lsl #4
+	aldc opc_fast_aldc, 2
+
+	// Handler for ldc_w MethodHandle
+# r2 = [jpc, #1]
+# r1 = [jpc, #2]
+	Opcode fast_aldc_w
+	// Fetch index bytes from bytecode
+	ldrb	r1, [jpc, #2]
+	DECACHE_STACK
+	orr	r1, r2, r1, lsl #8
+        add     r0, constpool, r1, lsl #4
+	aldc opc_fast_aldc_w, 3
+
 #ifdef FAST_BYTECODES
 # r2 = [jpc, #1]
 # r1 = [jpc, #2]
@@ -3507,6 +3652,7 @@
 	.byte	0
 	ALIGN_WORD
 
+invokedynamic_exception_fix:
 invokeinterface_exception_fix:
 	sub	jpc, jpc, #2
 invoke_exception_fix:
@@ -4974,7 +5120,7 @@
 	.word	do_invokespecial	@ 183 0xb7
 	.word	do_invokestatic	@ 184 0xb8
 	.word	do_invokeinterface	@ 185 0xb9
-	.word	do_undefined	@ 186 0xba
+	.word	do_invokedynamic	@ 186 0xba
 	.word	do_new	@ 187 0xbb
 	.word	do_newarray	@ 188 0xbc
 	.word	do_anewarray	@ 189 0xbd
@@ -5017,8 +5163,8 @@
 	.word	do_invokevfinal	@ 226 0xe2
 	.word	do_fast_iload_iload	@ 227 0xe3
 	.word	do_fast_iload_iload_N	@ 228 0xe4
-	.word	do_undefined	@ 229 0xe5
-	.word	do_undefined	@ 230 0xe6
+	.word	do_fast_aldc		@ 229 0xe5
+	.word	do_fast_aldc_w	@ 230 0xe6
 	.word	do_return_register_finalizer	@ 231 0xe7
 	.word	do_undefined	@ 232 0xe8
 	.word	do_iload_0_iconst_N	@ 233 0xe9
diff -r 30c4dc24823a -r a5d04cb60a5c src/cpu/zero/vm/thumb2.cpp
--- a/src/cpu/zero/vm/thumb2.cpp	Thu Mar 15 09:07:01 2012 -0400
+++ b/src/cpu/zero/vm/thumb2.cpp	Wed Apr 11 09:24:03 2012 -0400
@@ -239,6 +239,7 @@
 #define opc_invokespecial	0xb7
 #define opc_invokestatic	0xb8
 #define opc_invokeinterface	0xb9
+#define opc_invokedynamic	0xba
 #define opc_new			0xbb
 #define opc_newarray		0xbc
 #define opc_anewarray		0xbd
@@ -258,6 +259,9 @@
 
 #define OPC_LAST_JAVA_OP	0xca
 
+#define opc_fast_aldc		Bytecodes::_fast_aldc
+#define opc_fast_aldc_w		Bytecodes::_fast_aldc_w
+
 #define opc_bgetfield			0xcc
 #define opc_cgetfield			0xcd
 #define opc_igetfield			0xd0
@@ -413,6 +417,7 @@
 #endif // PRODUCT
 
 #define GET_NATIVE_U2(p)	(*(unsigned short *)(p))
+#define GET_NATIVE_U4(p)	(*(unsigned *)(p))
 
 #define GET_JAVA_S1(p)		(((signed char *)(p))[0])
 #define GET_JAVA_S2(p)  	((((signed char *)(p))[0] << 8) + (p)[1])
@@ -1166,7 +1171,7 @@
 	BCI(3, 0, 0, 1, 0, 0, 0, 0, 0),	// invokespecial
 	BCI(3, 0, 0, 1, 0, 0, 0, 0, 0),	// invokestatic
 	BCI(3, 0, 0, 1, 0, 0, 0, 0, 0),	// invokeinterface
-	BCI(0, 0, 0, 1, 0, 0, 0, 0, 0),	// xxxunusedxxx
+	BCI(5, 0, 0, 1, 0, 0, 0, 0, 0),	// invokedynamic
 	BCI(3, 0, 1, 0, 0, 0, 0, 0, 0),	// new
 	BCI(2, 1, 1, 0, 0, 0, 0, 0, 0),	// newarray
 	BCI(3, 1, 1, 0, 0, 0, 0, 0, 0),	// anewarray
@@ -1209,8 +1214,8 @@
 	BCI(3, 0, 0, 1, 0, 0, 0, 0, 0),	// invokevfinal
 	BCI(2, 0, 1, 0, 1, 0, 0, 0, BCI_TYPE_INT),	// iload_iload
 	BCI(2, 0, 1, 0, 1, 0, 0, 0, BCI_TYPE_INT),	// iload_iload_N
-	BCI(0, 0, 0, 1, 0, 0, 0, 0, 0),	// impdep1
-	BCI(0, 0, 0, 1, 0, 0, 0, 0, 0),	// impdep2
+	BCI(2, 0, 1, 0, 0, 0, 0, 0, 0),	// fast_aldc
+	BCI(3, 0, 1, 0, 0, 0, 0, 0, 0),	// fast_aldc_w
 	BCI(1, 0, 0, 1, 0, 0, 0, 0, 0),	// return_register_finalizer
 	BCI(1, 4, 2, 0, 0, 0, 0, 0, 0),	// dmac
 	BCI(1, 0, 1, 0, 1, 1, 0, 0, BCI_TYPE_INT),	// iload_0_iconst_N
@@ -1302,6 +1307,16 @@
 	break;
       }
 
+    case opc_invokedynamic:
+      bci += 5;
+      break;
+    case opc_fast_aldc_w:
+      bci += 3;
+      break;
+    case opc_fast_aldc:
+      bci += 2;
+      break;
+
       case opc_jsr: {
 	int off = GET_JAVA_S2(code_base+bci+1);
 	if (off < 0) bc_stackinfo[bci+off] |= BC_BACK_TARGET;
@@ -1804,6 +1819,21 @@
 	break;
       }
 
+      case opc_invokedynamic: {
+	int site_index = GET_NATIVE_U4(code_base+bci+1);
+	constantPoolOop pool = jinfo->method->constants();
+	int main_index = pool->cache()->secondary_entry_at(site_index)->main_entry_index();
+	// int pool_index = pool->cache()->entry_at(main_index)->constant_pool_index();
+	Symbol *sig = pool->signature_ref_at(main_index);
+	const jbyte *base = sig->base();
+
+	//tty->print("%d: %s: %s\n", opcode, name->as_C_string(), sig->as_C_string());
+	stackdepth += method_stackchange(base);
+	opcode = code_base[bci];
+	bci += 5;
+	break;
+      }
+
       case opc_invokeresolved:
       case opc_invokespecialresolved:
       case opc_invokestaticresolved:
@@ -5249,10 +5279,17 @@
     stackdepth = stackinfo & ~BC_FLAGS_MASK;
     bc_stackinfo[bci] = (stackinfo & BC_FLAGS_MASK) | (codebuf->idx * 2) | BC_COMPILED;
 
-    if (opcode > OPC_LAST_JAVA_OP && opcode != opc_return_register_finalizer) {
-      if (Bytecodes::is_defined((Bytecodes::Code)opcode))
-	opcode = (unsigned)Bytecodes::java_code((Bytecodes::Code)opcode);
-    }
+    if (opcode > OPC_LAST_JAVA_OP)
+      switch (opcode) {
+      default:
+	if (Bytecodes::is_defined((Bytecodes::Code)opcode))
+	  opcode = (unsigned)Bytecodes::java_code((Bytecodes::Code)opcode);
+	break;
+      case opc_return_register_finalizer:
+      case opc_fast_aldc_w:
+      case opc_fast_aldc:
+	break;
+      }
 
     len = Bytecodes::length_for((Bytecodes::Code)opcode);
     if (len <= 0) {
@@ -6546,6 +6583,31 @@
 	break;
       }
 
+    case opc_invokedynamic:
+      {
+	Thumb2_Exit(jinfo, H_EXIT_TO_INTERPRETER, bci, stackdepth);
+	break;
+      }
+
+    case opc_fast_aldc_w:
+    case opc_fast_aldc:
+      {
+	unsigned index = (opcode == (unsigned)opc_fast_aldc) ?
+				code_base[bci+1] : GET_NATIVE_U2(code_base+bci+1);
+	constantPoolOop constants = jinfo->method->constants();
+	ConstantPoolCacheEntry* cpce = constants->cache()->entry_at(index);
+        if (! cpce->is_f1_null()) {
+	  Thumb2_Spill(jinfo, 1, 0);
+	  int r = JSTACK_REG(jstack);
+	  PUSH(jstack, r);
+	  ldr_imm(jinfo->codebuf, r, Ristate, ISTATE_CONSTANTS, 1, 0);
+	  ldr_imm(jinfo->codebuf, r, r, CP_OFFSET + (index << 4) + 4, 1, 0); // offset to cache->f1()
+	} else {
+	  Thumb2_Exit(jinfo, H_EXIT_TO_INTERPRETER, bci, stackdepth);
+	}
+	break;
+      }
+
       case opc_jsr_w:
       case opc_jsr: {
 	Thumb2_Jsr(jinfo , bci, stackdepth);


From ahughes at redhat.com  Wed Apr 11 06:34:45 2012
From: ahughes at redhat.com (Andrew Hughes)
Date: Wed, 11 Apr 2012 09:34:45 -0400 (EDT)
Subject: RFC: icedtea7-2.1: Bump Hotspot to bring in unified syntax for
	thumb	code and support glib >= 2.32.
In-Reply-To: <4F857BB1.40109@zafena.se>
Message-ID: <9d846935-2079-4912-a389-23a5cb51c2ee@zmail17.collab.prod.int.phx2.redhat.com>

----- Original Message -----
> Hi team,
> I would like to commit two changes to the icedtea7-2.1 release
> branch.
> 
> 1. a fix for a missing -lgthread-2.0 to gcc that cause the following
> error:
> src/solaris/native/sun/awt/gtk2_interface.c:218: undefined reference
> to `g_thread_init'
> http://icedtea.classpath.org/hg/icedtea7/raw-rev/ab3f4766a208
> 
> 2. and a bump of the hotspot changeset to bring in;
> http://icedtea.classpath.org/hg/release/icedtea7-forest-2.1/hotspot/rev/26f5d8596931
> this part was missing in the recent arm_port import from icedtea6
> into icedtea7. It fixes the following compile error on thumb2 arm
> systems:
> /build/buildd/openjdk-7-7~u3-2.1.1~pre1/build/openjdk-boot/hotspot/src/cpu/zero/vm/arm_cas.S:
> Assembler messages:
> /build/buildd/openjdk-7-7~u3-2.1.1~pre1/build/openjdk-boot/hotspot/src/cpu/zero/vm/arm_cas.S:13:
> Error: lo register required -- `stmfd sp!,{r4,r5,r6,r7}'
> /build/buildd/openjdk-7-7~u3-2.1.1~pre1/build/openjdk-boot/hotspot/src/cpu/zero/vm/arm_cas.S:19:
> Error: Thumb does not support conditional execution
> /build/buildd/openjdk-7-7~u3-2.1.1~pre1/build/openjdk-boot/hotspot/src/cpu/zero/vm/arm_cas.S:20:
> Error: incorrect condition in IT block -- `bne 1f'
> /build/buildd/openjdk-7-7~u3-2.1.1~pre1/build/openjdk-boot/hotspot/src/cpu/zero/vm/arm_cas.S:27:
> Error: lo register required -- `ldmfd sp!,{r4,r5,r6,r7}'
> make[8]: *** [arm_cas.o] Error 1
> 
> Cheers
> Xerxes
> 

Approved.

> 
> diff -r 8ea793eccbd1 ChangeLog
> --- a/ChangeLog	Tue Apr 03 01:16:08 2012 +0100
> +++ b/ChangeLog	Wed Apr 11 15:34:11 2012 +0200
> @@ -1,3 +1,15 @@
> +2012-04-11  Xerxes R?nby  <xerxes at zafena.se>
> +
> +	* Makefile.am:
> +	(HOTSPOT_CHANGESET): Sync to HEAD.
> +	(HOTSPOT_SHA256SUM): Likewise.
> +
> +2012-04-06  Andrew John Hughes  <ahughes at redhat.com>
> +
> +	* acinclude.m4:
> +	(IT_CHECK_FOR_GTK): Work with glib >= 2.32
> +	by explicitly asking for gthread.
> +
>  2012-03-29  Andrew John Hughes  <ahughes at redhat.com>
> 
>           * Makefile.am:
> diff -r 8ea793eccbd1 Makefile.am
> --- a/Makefile.am	Tue Apr 03 01:16:08 2012 +0100
> +++ b/Makefile.am	Wed Apr 11 15:34:11 2012 +0200
> @@ -5,7 +5,7 @@
>  COMBINED_VERSION = $(JDK_UPDATE_VERSION)-$(OPENJDK_VERSION)
> 
>  CORBA_CHANGESET = 5617f6c5cc94
> -HOTSPOT_CHANGESET = 30c4dc24823a
> +HOTSPOT_CHANGESET = 26f5d8596931
>  JAXP_CHANGESET = 1cf75c0e2c96
>  JAXWS_CHANGESET = 7edfbfe974f2
>  JDK_CHANGESET = 2d8ad70a2243
> @@ -13,7 +13,7 @@
>  OPENJDK_CHANGESET = 22cc03983e20
> 
>  CORBA_SHA256SUM =
>  963915483530f311ff313635f79ed11ea7ce5a1c0dbee5d1acb1994132857fa3
> -HOTSPOT_SHA256SUM =
> 1a9290c85a280a21256c96e98f2461a88481d63fc4792725845caaeb155fa623
> +HOTSPOT_SHA256SUM =
> 3bf8b0a93105a0a6dbc657eaf7c95b5dd9a8dc478544e75b9e90571632f6a522
>  JAXP_SHA256SUM =
>  8ce48c704f38285207ee6dc56c45b2d214083b4d4d36be02901401b594ce701e
>  JAXWS_SHA256SUM =
>  823ca6b8fd780bf1b1565a90cfc8ec6f0ee422a5d25ffb20b1ce0272dc4955aa
>  JDK_SHA256SUM =
>  a3f1748212086feb3351772c1bc3eb6a2918fac474a37bec219d97b668676f40
> diff -r 8ea793eccbd1 acinclude.m4
> --- a/acinclude.m4	Tue Apr 03 01:16:08 2012 +0100
> +++ b/acinclude.m4	Wed Apr 11 15:34:11 2012 +0200
> @@ -2011,7 +2011,7 @@
>    AC_MSG_RESULT(${ENABLE_SYSTEM_GTK})
>    if test x"${ENABLE_SYSTEM_GTK}" = "xyes"; then
>      dnl Check for Gtk+ headers and libraries.
> -    PKG_CHECK_MODULES(GTK, gtk+-2.0,[GTK_FOUND=yes],[GTK_FOUND=no])
> +    PKG_CHECK_MODULES(GTK, gtk+-2.0
> gthread-2.0,[GTK_FOUND=yes],[GTK_FOUND=no])
>      if test "x${GTK_FOUND}" = xno
>      then
>        AC_MSG_ERROR([Could not find Gtk+; install Gtk+ or build with
>        --disable-system-gtk to use the in-tree headers.])
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From xranby at icedtea.classpath.org  Wed Apr 11 06:35:51 2012
From: xranby at icedtea.classpath.org (xranby at icedtea.classpath.org)
Date: Wed, 11 Apr 2012 13:35:51 +0000
Subject: /hg/release/icedtea7-2.1: 2 new changesets
Message-ID: <hg.5d772a4e7dd7.1334151351.5789328834432805217@icedtea.classpath.org>

changeset 5d772a4e7dd7 in /hg/release/icedtea7-2.1
details: http://icedtea.classpath.org/hg/release/icedtea7-2.1?cmd=changeset;node=5d772a4e7dd7
author: Andrew John Hughes <ahughes at redhat.com>
date: Fri Apr 06 18:28:57 2012 +0100

	Support glib >= 2.32.

	2012-04-06  Andrew John Hughes  <ahughes at redhat.com>

		* acinclude.m4:
		(IT_CHECK_FOR_GTK): Work with glib >= 2.32
		by explicitly asking for gthread.


changeset ae30f070f936 in /hg/release/icedtea7-2.1
details: http://icedtea.classpath.org/hg/release/icedtea7-2.1?cmd=changeset;node=ae30f070f936
author: Xerxes Ranby <xerxes at zafena.se>
date: Wed Apr 11 15:32:59 2012 +0200

	Bump HotSpot changes to bring in unified syntax for thumb code.

	2012-04-11  Xerxes Ranby  <xerxes at zafena.se>

	        * Makefile.am:
	        (HOTSPOT_CHANGESET): Sync to HEAD.
	        (HOTSPOT_SHA256SUM): Likewise.


diffstat:

 ChangeLog    |  12 ++++++++++++
 Makefile.am  |   4 ++--
 acinclude.m4 |   2 +-
 3 files changed, 15 insertions(+), 3 deletions(-)

diffs (52 lines):

diff -r 8ea793eccbd1 -r ae30f070f936 ChangeLog
--- a/ChangeLog	Tue Apr 03 01:16:08 2012 +0100
+++ b/ChangeLog	Wed Apr 11 15:32:59 2012 +0200
@@ -1,3 +1,15 @@
+2012-04-11  Xerxes R??nby  <xerxes at zafena.se>
+
+	* Makefile.am:
+	(HOTSPOT_CHANGESET): Sync to HEAD.
+	(HOTSPOT_SHA256SUM): Likewise.
+
+2012-04-06  Andrew John Hughes  <ahughes at redhat.com>
+
+	* acinclude.m4:
+	(IT_CHECK_FOR_GTK): Work with glib >= 2.32
+	by explicitly asking for gthread.
+
 2012-03-29  Andrew John Hughes  <ahughes at redhat.com>
 
          * Makefile.am:
diff -r 8ea793eccbd1 -r ae30f070f936 Makefile.am
--- a/Makefile.am	Tue Apr 03 01:16:08 2012 +0100
+++ b/Makefile.am	Wed Apr 11 15:32:59 2012 +0200
@@ -5,7 +5,7 @@
 COMBINED_VERSION = $(JDK_UPDATE_VERSION)-$(OPENJDK_VERSION)
 
 CORBA_CHANGESET = 5617f6c5cc94
-HOTSPOT_CHANGESET = 30c4dc24823a
+HOTSPOT_CHANGESET = 26f5d8596931
 JAXP_CHANGESET = 1cf75c0e2c96
 JAXWS_CHANGESET = 7edfbfe974f2
 JDK_CHANGESET = 2d8ad70a2243
@@ -13,7 +13,7 @@
 OPENJDK_CHANGESET = 22cc03983e20
 
 CORBA_SHA256SUM = 963915483530f311ff313635f79ed11ea7ce5a1c0dbee5d1acb1994132857fa3
-HOTSPOT_SHA256SUM = 1a9290c85a280a21256c96e98f2461a88481d63fc4792725845caaeb155fa623
+HOTSPOT_SHA256SUM = 3bf8b0a93105a0a6dbc657eaf7c95b5dd9a8dc478544e75b9e90571632f6a522
 JAXP_SHA256SUM = 8ce48c704f38285207ee6dc56c45b2d214083b4d4d36be02901401b594ce701e
 JAXWS_SHA256SUM = 823ca6b8fd780bf1b1565a90cfc8ec6f0ee422a5d25ffb20b1ce0272dc4955aa
 JDK_SHA256SUM = a3f1748212086feb3351772c1bc3eb6a2918fac474a37bec219d97b668676f40
diff -r 8ea793eccbd1 -r ae30f070f936 acinclude.m4
--- a/acinclude.m4	Tue Apr 03 01:16:08 2012 +0100
+++ b/acinclude.m4	Wed Apr 11 15:32:59 2012 +0200
@@ -2011,7 +2011,7 @@
   AC_MSG_RESULT(${ENABLE_SYSTEM_GTK})
   if test x"${ENABLE_SYSTEM_GTK}" = "xyes"; then
     dnl Check for Gtk+ headers and libraries.
-    PKG_CHECK_MODULES(GTK, gtk+-2.0,[GTK_FOUND=yes],[GTK_FOUND=no])
+    PKG_CHECK_MODULES(GTK, gtk+-2.0 gthread-2.0,[GTK_FOUND=yes],[GTK_FOUND=no])
     if test "x${GTK_FOUND}" = xno
     then
       AC_MSG_ERROR([Could not find Gtk+; install Gtk+ or build with --disable-system-gtk to use the in-tree headers.])


From ahughes at redhat.com  Wed Apr 11 07:03:02 2012
From: ahughes at redhat.com (Andrew Hughes)
Date: Wed, 11 Apr 2012 10:03:02 -0400 (EDT)
Subject: ARM: JSR 292 MethodHandle support
In-Reply-To: <4F857616.8050203@redhat.com>
Message-ID: <e72ac8db-548c-497f-b548-3bf07a13166a@zmail17.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> Hi,
> 
> Better late than never, included below is a review of Andrew's patch.
> 
> regards,
> 
> 
> Andrew Dinn
> -----------

snip...

>   * jdk/make/common/shared/Compiler-gcc.gmk
> 
> This was setting
> 
>    SHARED_LIBRARY_FLAG = -shared -mimpure-text
> 
> but the second flag is invalid for arm (or indeed anything other than
> SPARC according to the gcc manual). So it needs to be removed.
>

As mentioned on IRC, you need:

changeset:   5125:fb3a2cafc230
parent:      5097:c5b882dce0fe
user:        andrew
date:        Thu Mar 08 14:04:44 2012 +0000
files:       make/common/shared/Compiler-gcc.gmk src/share/demo/jvmti/compiledMethodLoad/sample.makefile.txt src/share/demo/jvmti/gctest/sample.makefile.txt src/share/demo/jvmti/heapTracker/sample.makefile.txt src/share/demo/jvmti/heapViewer/sample.makefile.txt src/share/demo/jvmti/hprof/sample.makefile.txt src/share/demo/jvmti/index.html src/share/demo/jvmti/java_crw_demo/sample.makefile.txt src/share/demo/jvmti/minst/sample.makefile.txt src/share/demo/jvmti/mtrace/sample.makefile.txt src/share/demo/jvmti/versionCheck/sample.makefile.txt src/share/demo/jvmti/waiters/sample.makefile.txt
description:
7150392: Linux build breaks with GCC 4.7 due to unrecognized option
Summary: Remove -mimpure-text option.
Reviewed-by: ohair, dholmes, phh, andrew
Contributed-by: Deepak Bhole <dbhole at redhat.com>

This only seems to be in OpenJDK8 and not been followed through to relevant branches.
I've pushed it to IcedTea7 and will request an approval for jdk7u.
I pre-approve you adding it to 2.1.
 
>   * jdk/make/jdk_generic_profile.sh
> 
> This script needs an entry for arm in the case switch at line 283
> i.e.
> 
>     # ZERO_ENDIANNESS is the endianness of the processor
>     case "${ZERO_LIBARCH}" in
> -    i386|amd64|ia64)
> +    i386|amd64|ia64|arm)
> 
> and also another case at line 310 i.e.
> 
>       s390)
>         ZERO_ARCHFLAG="-m31"
>         ;;
> +    arm)
> +      ZERO_ARCHFLAG="-D_LITTLE_ENDIAN"
> +      ;;
>       *)
> 

This file is not used by the IcedTea build system which is, I guess, why these
haven't been updated.  Any changes need to go to both IcedTea7 and 2.0 & 2.1 branches.
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From bugzilla-daemon at icedtea.classpath.org  Wed Apr 11 07:26:56 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Wed, 11 Apr 2012 14:26:56 +0000
Subject: [Bug 917] plugin crashes when calling javascript function
In-Reply-To: <bug-917-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-917-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-917-30-ewAGa3irkb@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=917

Don <donmyers at myersfarm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |donmyers at myersfarm.com

--- Comment #1 from Don <donmyers at myersfarm.com> 2012-04-11 14:26:56 UTC ---
I had no problems using IcedTea plugin 1.1.3- 1ubuntu1.1 with Chrome Beta in
Ubuntu 11.10. I've upgraded four computers to 12.04 Beta 2 within the last
week. All are using a newer 1.2 series IcedTea Plugin, which was updated in the
updates that came out yesterday/last night. I do my own real estate website and
use applets for the main navigation, as well as for marquees. The newer version
of Iced Tea works perfectly with Firefox in Ubuntu 12.04. It crashed very
frequently in Chrome Beta before yesterday's updates. Since the updates, the
crashes are not as frequent, but they still occur. Firefox is still fine. I've
replicated this on three of the four machines running Ubuntu 12.04. I don't
have access to try it on the fourth. I'm sorry, but I'm not a programmer. If
you want me to try to run something to check out, please tell me how to do
whatever, and I will do it. The site I'm experiencing the issues with is
http://www.cbur-ruralproperty.com . The menu is just under the logo. With the
present updates I generally, in Chrome beta, need to refresh the page to get
the menu to come up. Then if I click on the various links, by about the third
or fourth page the plugin crashes.

-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


From andrew at icedtea.classpath.org  Wed Apr 11 10:36:11 2012
From: andrew at icedtea.classpath.org (andrew at icedtea.classpath.org)
Date: Wed, 11 Apr 2012 17:36:11 +0000
Subject: /hg/icedtea7: Allow downloading to be disabled.
Message-ID: <hg.2c3f32cee817.1334165771.2873452341184383833@icedtea.classpath.org>

changeset 2c3f32cee817 in /hg/icedtea7
details: http://icedtea.classpath.org/hg/icedtea7?cmd=changeset;node=2c3f32cee817
author: Andrew John Hughes <ahughes at redhat.com>
date: Wed Apr 11 18:36:03 2012 +0100

	Allow downloading to be disabled.

	2012-04-11  Andrew John Hughes  <ahughes at redhat.com>

		* Makefile.am:
		(download-openjdk): Don't download unless
		enable_downloading is set.
		(download-cacao): Likewise.
		(download-jamvm): Likewise.
		* acinclude.m4:
		(IT_CHECK_FOR_DOWNLOADING): New option
		--disable-downloading.
		* configure.ac: Call IT_CHECK_FOR_DOWNLOADING.


diffstat:

 ChangeLog    |   12 ++++
 Makefile.am  |  173 ++++++++++++++++++++++++++++++++++------------------------
 acinclude.m4 |   23 +++++++
 configure.ac |    1 +
 4 files changed, 136 insertions(+), 73 deletions(-)

diffs (307 lines):

diff -r d9400e955e0f -r 2c3f32cee817 ChangeLog
--- a/ChangeLog	Fri Apr 06 20:52:28 2012 +0100
+++ b/ChangeLog	Wed Apr 11 18:36:03 2012 +0100
@@ -1,3 +1,15 @@
+2012-04-11  Andrew John Hughes  <ahughes at redhat.com>
+
+	* Makefile.am:
+	(download-openjdk): Don't download unless
+	enable_downloading is set.
+	(download-cacao): Likewise.
+	(download-jamvm): Likewise.
+	* acinclude.m4:
+	(IT_CHECK_FOR_DOWNLOADING): New option
+	--disable-downloading.
+	* configure.ac: Call IT_CHECK_FOR_DOWNLOADING.
+
 2012-04-06  Andrew John Hughes  <ahughes at redhat.com>
 
 	* Makefile.am:
diff -r d9400e955e0f -r 2c3f32cee817 Makefile.am
--- a/Makefile.am	Fri Apr 06 20:52:28 2012 +0100
+++ b/Makefile.am	Wed Apr 11 18:36:03 2012 +0100
@@ -855,15 +855,18 @@
 	if ! echo "$(OPENJDK_SHA256SUM)  $(OPENJDK_SRC_ZIP)" \
 	  | $(SHA256SUM) --check ; \
 	then \
-	  if [ -e $(OPENJDK_SRC_ZIP) ] ; \
-	  then \
-	    mv $(OPENJDK_SRC_ZIP) $(OPENJDK_SRC_ZIP).old ; \
+	  if test "x$${enable_downloading}" = "xyes"; then \
+	    if [ -e $(OPENJDK_SRC_ZIP) ] ; then \
+	      mv $(OPENJDK_SRC_ZIP) $(OPENJDK_SRC_ZIP).old ; \
+	    fi ; \
+	    $(WGET) $(OPENJDK_URL)/archive/$(OPENJDK_CHANGESET).tar.gz -O $(OPENJDK_SRC_ZIP); \
+	    if ! echo "$(OPENJDK_SHA256SUM)  $(OPENJDK_SRC_ZIP)" \
+	      | $(SHA256SUM) --check ; then \
+	      echo "ERROR: Bad download of OpenJDK root zip"; false; \
+	    fi; \
+	  else \
+	    echo "ERROR: No up-to-date OpenJDK root zip available"; exit -1; \
 	  fi ; \
-	  $(WGET) $(OPENJDK_URL)/archive/$(OPENJDK_CHANGESET).tar.gz -O $(OPENJDK_SRC_ZIP); \
-	  if ! echo "$(OPENJDK_SHA256SUM)  $(OPENJDK_SRC_ZIP)" \
-	    | $(SHA256SUM) --check ; \
-	  then echo "ERROR: Bad download of OpenJDK root zip"; false; \
-	  fi; \
 	fi ;
 if USE_ALT_CORBA_SRC_ZIP
 	ln -sf $(ALT_CORBA_SRC_ZIP) $(CORBA_SRC_ZIP)
@@ -871,15 +874,18 @@
 	if ! echo "$(CORBA_SHA256SUM)  $(CORBA_SRC_ZIP)" \
 	  | $(SHA256SUM) --check ; \
 	then \
-	  if [ $(CORBA_SRC_ZIP) ] ; \
-	  then \
-	    mv $(CORBA_SRC_ZIP) $(CORBA_SRC_ZIP).old ; \
+	  if test "x$${enable_downloading}" = "xyes"; then \
+	    if [ $(CORBA_SRC_ZIP) ] ; then \
+	      mv $(CORBA_SRC_ZIP) $(CORBA_SRC_ZIP).old ; \
+	    fi ; \
+	    $(WGET) $(CORBA_URL)/archive/$(CORBA_CHANGESET).tar.gz -O $(CORBA_SRC_ZIP); \
+	    if ! echo "$(CORBA_SHA256SUM)  $(CORBA_SRC_ZIP)" \
+	      | $(SHA256SUM) --check ; then \
+	      echo "ERROR: Bad download of CORBA zip"; false; \
+	    fi; \
+	  else \
+	    echo "ERROR: No up-to-date OpenJDK CORBA zip available"; exit -1; \
 	  fi ; \
-	  $(WGET) $(CORBA_URL)/archive/$(CORBA_CHANGESET).tar.gz -O $(CORBA_SRC_ZIP); \
-	  if ! echo "$(CORBA_SHA256SUM)  $(CORBA_SRC_ZIP)" \
-	    | $(SHA256SUM) --check ; \
-	  then echo "ERROR: Bad download of CORBA zip"; false; \
-	  fi; \
 	fi ;
 if USE_ALT_JAXP_SRC_ZIP
 	ln -sf $(ALT_JAXP_SRC_ZIP) $(JAXP_SRC_ZIP)
@@ -887,15 +893,18 @@
 	if ! echo "$(JAXP_SHA256SUM)  $(JAXP_SRC_ZIP)" \
 	  | $(SHA256SUM) --check ; \
 	then \
-	  if [ $(JAXP_SRC_ZIP) ] ; \
-	  then \
-	    mv $(JAXP_SRC_ZIP) $(JAXP_SRC_ZIP).old ; \
+	  if test "x$${enable_downloading}" = "xyes"; then \
+	    if [ $(JAXP_SRC_ZIP) ] ; then \
+	      mv $(JAXP_SRC_ZIP) $(JAXP_SRC_ZIP).old ; \
+	    fi ; \
+	    $(WGET) $(JAXP_URL)/archive/$(JAXP_CHANGESET).tar.gz -O $(JAXP_SRC_ZIP); \
+	    if ! echo "$(JAXP_SHA256SUM)  $(JAXP_SRC_ZIP)" \
+	      | $(SHA256SUM) --check ; then \
+	      echo "ERROR: Bad download of JAXP zip"; false; \
+	    fi; \
+	  else \
+	    echo "ERROR: No up-to-date JAXP root zip available"; exit -1; \
 	  fi ; \
-	  $(WGET) $(JAXP_URL)/archive/$(JAXP_CHANGESET).tar.gz -O $(JAXP_SRC_ZIP); \
-	  if ! echo "$(JAXP_SHA256SUM)  $(JAXP_SRC_ZIP)" \
-	    | $(SHA256SUM) --check ; \
-	  then echo "ERROR: Bad download of JAXP zip"; false; \
-	  fi; \
 	fi ;
 if USE_ALT_JAXWS_SRC_ZIP
 	ln -sf $(ALT_JAXWS_SRC_ZIP) $(JAXWS_SRC_ZIP)
@@ -903,15 +912,18 @@
 	if ! echo "$(JAXWS_SHA256SUM)  $(JAXWS_SRC_ZIP)" \
 	  | $(SHA256SUM) --check ; \
 	then \
-	  if [ $(JAXWS_SRC_ZIP) ] ; \
-	  then \
-	    mv $(JAXWS_SRC_ZIP) $(JAXWS_SRC_ZIP).old ; \
+	  if test "x$${enable_downloading}" = "xyes"; then \
+	    if [ $(JAXWS_SRC_ZIP) ] ; then \
+	      mv $(JAXWS_SRC_ZIP) $(JAXWS_SRC_ZIP).old ; \
+	    fi ; \
+	    $(WGET) $(JAXWS_URL)/archive/$(JAXWS_CHANGESET).tar.gz -O $(JAXWS_SRC_ZIP); \
+	    if ! echo "$(JAXWS_SHA256SUM)  $(JAXWS_SRC_ZIP)" \
+	      | $(SHA256SUM) --check ; then \
+	      echo "ERROR: Bad download of JAXWS zip"; false; \
+	    fi; \
+	  else \
+	    echo "ERROR: No up-to-date OpenJDK JAXWS zip available"; exit -1; \
 	  fi ; \
-	  $(WGET) $(JAXWS_URL)/archive/$(JAXWS_CHANGESET).tar.gz -O $(JAXWS_SRC_ZIP); \
-	  if ! echo "$(JAXWS_SHA256SUM)  $(JAXWS_SRC_ZIP)" \
-	    | $(SHA256SUM) --check ; \
-	  then echo "ERROR: Bad download of JAXWS zip"; false; \
-	  fi; \
 	fi ;
 if USE_ALT_JDK_SRC_ZIP
 	ln -sf $(ALT_JDK_SRC_ZIP) $(JDK_SRC_ZIP)
@@ -919,15 +931,18 @@
 	if ! echo "$(JDK_SHA256SUM)  $(JDK_SRC_ZIP)" \
 	  | $(SHA256SUM) --check ; \
 	then \
-	  if [ $(JDK_SRC_ZIP) ] ; \
-	  then \
-	    mv $(JDK_SRC_ZIP) $(JDK_SRC_ZIP).old ; \
+	  if test "x$${enable_downloading}" = "xyes"; then \
+	    if [ $(JDK_SRC_ZIP) ] ; then \
+	      mv $(JDK_SRC_ZIP) $(JDK_SRC_ZIP).old ; \
+	    fi ; \
+	    $(WGET) $(JDK_URL)/archive/$(JDK_CHANGESET).tar.gz -O $(JDK_SRC_ZIP); \
+	    if ! echo "$(JDK_SHA256SUM)  $(JDK_SRC_ZIP)" \
+	      | $(SHA256SUM) --check ; then \
+	      echo "ERROR: Bad download of JDK zip"; false; \
+	    fi; \
+	  else \
+	    echo "ERROR: No up-to-date OpenJDK JDK zip available"; exit -1; \
 	  fi ; \
-	  $(WGET) $(JDK_URL)/archive/$(JDK_CHANGESET).tar.gz -O $(JDK_SRC_ZIP); \
-	  if ! echo "$(JDK_SHA256SUM)  $(JDK_SRC_ZIP)" \
-	    | $(SHA256SUM) --check ; \
-	  then echo "ERROR: Bad download of JDK zip"; false; \
-	  fi; \
 	fi ;
 if USE_ALT_LANGTOOLS_SRC_ZIP
 	ln -sf $(ALT_LANGTOOLS_SRC_ZIP) $(LANGTOOLS_SRC_ZIP)
@@ -935,15 +950,18 @@
 	if ! echo "$(LANGTOOLS_SHA256SUM)  $(LANGTOOLS_SRC_ZIP)" \
 	  | $(SHA256SUM) --check ; \
 	then \
-	  if [ $(LANGTOOLS_SRC_ZIP) ] ; \
-	  then \
-	    mv $(LANGTOOLS_SRC_ZIP) $(LANGTOOLS_SRC_ZIP).old ; \
+	  if test "x$${enable_downloading}" = "xyes"; then \
+	    if [ $(LANGTOOLS_SRC_ZIP) ] ; then \
+	      mv $(LANGTOOLS_SRC_ZIP) $(LANGTOOLS_SRC_ZIP).old ; \
+	    fi ; \
+	    $(WGET) $(LANGTOOLS_URL)/archive/$(LANGTOOLS_CHANGESET).tar.gz -O $(LANGTOOLS_SRC_ZIP); \
+	    if ! echo "$(LANGTOOLS_SHA256SUM)  $(LANGTOOLS_SRC_ZIP)" \
+	      | $(SHA256SUM) --check ; then \
+	      echo "ERROR: Bad download of langtools zip"; false; \
+	    fi; \
+	  else \
+	    echo "ERROR: No up-to-date OpenJDK langtools zip available"; exit -1; \
 	  fi ; \
-	  $(WGET) $(LANGTOOLS_URL)/archive/$(LANGTOOLS_CHANGESET).tar.gz -O $(LANGTOOLS_SRC_ZIP); \
-	  if ! echo "$(LANGTOOLS_SHA256SUM)  $(LANGTOOLS_SRC_ZIP)" \
-	    | $(SHA256SUM) --check ; \
-	  then echo "ERROR: Bad download of langtools zip"; false; \
-	  fi; \
 	fi ;
 if USE_ALT_HOTSPOT_SRC_ZIP
 	ln -sf $(ALT_HOTSPOT_SRC_ZIP) $(HOTSPOT_SRC_ZIP)
@@ -951,15 +969,18 @@
 	if ! echo "$(HS_SHA256SUM)  $(HOTSPOT_SRC_ZIP)" \
 	  | $(SHA256SUM) --check ; \
 	then \
-	  if [ -e $(HOTSPOT_SRC_ZIP) ] ; \
-	  then \
-	    mv $(HOTSPOT_SRC_ZIP) $(HOTSPOT_SRC_ZIP).old ; \
+	  if test "x$${enable_downloading}" = "xyes"; then \
+	    if [ -e $(HOTSPOT_SRC_ZIP) ] ; then \
+	      mv $(HOTSPOT_SRC_ZIP) $(HOTSPOT_SRC_ZIP).old ; \
+	    fi ; \
+	    $(WGET) $(HS_URL)/archive/$(HS_CHANGESET).tar.gz -O $(HOTSPOT_SRC_ZIP) ; \
+	    if ! echo "$(HOTSPOT_SHA256SUM)  $(HOTSPOT_SRC_ZIP)" \
+	      | $(SHA256SUM) --check ; then \
+	      echo "ERROR: Bad download of HotSpot zip"; false; \
+	    fi; \
+	  else \
+	    echo "ERROR: No up-to-date OpenJDK HotSpot zip available"; exit -1; \
 	  fi ; \
-	  $(WGET) $(HS_URL)/archive/$(HS_CHANGESET).tar.gz -O $(HOTSPOT_SRC_ZIP) ; \
-	  if ! echo "$(HOTSPOT_SHA256SUM)  $(HOTSPOT_SRC_ZIP)" \
-	    | $(SHA256SUM) --check ; \
-	  then echo "ERROR: Bad download of HotSpot zip"; false; \
-	  fi; \
 	fi
 endif
 endif
@@ -1005,15 +1026,18 @@
 	if ! echo "$(CACAO_SHA256SUM)  $(CACAO_SRC_ZIP)" \
 	 | $(SHA256SUM) --check ; \
 	then \
-	 if [ -e $(CACAO_SRC_ZIP) ] ; \
-	 then \
-	   mv $(CACAO_SRC_ZIP) $(CACAO_SRC_ZIP).old ; \
+	 if test "x$${enable_downloading}" = "xyes"; then \
+	   if [ -e $(CACAO_SRC_ZIP) ] ; then \
+	     mv $(CACAO_SRC_ZIP) $(CACAO_SRC_ZIP).old ; \
+	   fi ; \
+	   $(WGET) $(CACAO_URL) -O $(CACAO_SRC_ZIP); \
+	   if ! echo "$(CACAO_SHA256SUM)  $(CACAO_SRC_ZIP)" \
+	     | $(SHA256SUM) --check ; then \
+	     echo "ERROR: Bad download of CACAO zip"; false; \
+	   fi; \
+	 else \
+	   echo "ERROR: No up-to-date CACAO zip available"; exit -1; \
 	 fi ; \
-	 $(WGET) $(CACAO_URL) -O $(CACAO_SRC_ZIP); \
-	 if ! echo "$(CACAO_SHA256SUM)  $(CACAO_SRC_ZIP)" \
-	   | $(SHA256SUM) --check ; \
-	 then echo "ERROR: Bad download of CACAO zip"; false; \
-	 fi; \
 	fi
 endif
 endif
@@ -1032,15 +1056,18 @@
 	if ! echo "$(JAMVM_SHA256SUM)  $(JAMVM_SRC_ZIP)" \
 	 | $(SHA256SUM) --check ; \
 	then \
-	 if [ -e $(JAMVM_SRC_ZIP) ] ; \
-	 then \
-	   mv $(JAMVM_SRC_ZIP) $(JAMVM_SRC_ZIP).old ; \
-	 fi ; \
-	 $(WGET) $(JAMVM_URL) -O $(JAMVM_SRC_ZIP); \
-	 if ! echo "$(JAMVM_SHA256SUM)  $(JAMVM_SRC_ZIP)" \
-	  | $(SHA256SUM) --check ; \
-	 then echo "ERROR: Bad download of JamVM zip"; false; \
-	 fi; \
+	  if test "x$${enable_downloading}" = "xyes"; then \
+	    if [ -e $(JAMVM_SRC_ZIP) ] ; then \
+	      mv $(JAMVM_SRC_ZIP) $(JAMVM_SRC_ZIP).old ; \
+	    fi ; \
+	    $(WGET) $(JAMVM_URL) -O $(JAMVM_SRC_ZIP); \
+	    if ! echo "$(JAMVM_SHA256SUM)  $(JAMVM_SRC_ZIP)" \
+	      | $(SHA256SUM) --check ; then \
+	      echo "ERROR: Bad download of JamVM zip"; false; \
+	    fi; \
+	  else \
+	    echo "ERROR: No up-to-date JamVM zip available"; exit -1; \
+	  fi ; \
 	fi
 endif
 	mkdir -p stamps
diff -r d9400e955e0f -r 2c3f32cee817 acinclude.m4
--- a/acinclude.m4	Fri Apr 06 20:52:28 2012 +0100
+++ b/acinclude.m4	Wed Apr 11 18:36:03 2012 +0100
@@ -2178,3 +2178,26 @@
 AM_CONDITIONAL([NO_BYTECODE7], test x"${it_cv_bytecode7}" = "xyes")
 AC_PROVIDE([$0])dnl
 ])
+
+AC_DEFUN([IT_CHECK_IF_DOWNLOADING],
+[
+  AC_MSG_CHECKING([whether to download tarballs])
+  AC_ARG_ENABLE([downloading],
+	      [AS_HELP_STRING(--disable-downloading,don't download tarballs [[default=no]])],
+  [
+    case "${enableval}" in
+      no)
+	enable_downloading=no
+        ;;
+      *)
+        enable_downloading=yes
+        ;;
+    esac
+  ],
+  [
+        enable_downloading=yes
+  ])
+  AC_MSG_RESULT([${enable_downloading}])
+  AM_CONDITIONAL([DOWNLOADING], test x"${enable_downloading}" = "xyes")
+  AC_SUBST([enable_downloading])
+])
diff -r d9400e955e0f -r 2c3f32cee817 configure.ac
--- a/configure.ac	Fri Apr 06 20:52:28 2012 +0100
+++ b/configure.ac	Wed Apr 11 18:36:03 2012 +0100
@@ -94,6 +94,7 @@
 
 IT_CHECK_NUMBER_OF_PARALLEL_JOBS
 IT_CHECK_IF_BOOTSTRAPPING
+IT_CHECK_IF_DOWNLOADING
 IT_CHECK_FOR_JDK
 IT_FIND_JAVA
 IT_FIND_JAVA_COMPILER


From ddadacha at redhat.com  Wed Apr 11 11:55:07 2012
From: ddadacha at redhat.com (Danesh Dadachanji)
Date: Wed, 11 Apr 2012 14:55:07 -0400
Subject: [rfc][icedtea-web] signed applets test
In-Reply-To: <4F85501C.1080003@redhat.com>
References: <4F85501C.1080003@redhat.com>
Message-ID: <4F85D38B.6060502@redhat.com>

Hi Jiri,

Nice work! I have a few comments below.

On 11/04/12 05:34 AM, Jiri Vanek wrote:
> Hi!
>
> This is implementation of what we have agreed for signed applets - add(and remove) certificate to ~/.icedtea/security/trusted.certs,
> launch applet signed by this cert in explorer and read stdout/in as we are doing for applet tests right now.
>
> There is question how to deal with -Xtrustall which is now useless when there is trusted certificate (all signed reproducers are right
> now signed with same cert, and when more to much reproducers will need to much different certificates this will need re-factoring
> probably too).
>

I don't mind -Xtrustall staying, I think it helps for testing stuff on the fly, outside the test suite. However, I'm not too strong 
about this so if you want to remove it, feel free.

> After this change is in, the PR905 reproducer have sense to go in too.
>

+1

> changelog:
>
> 2012-04-11 Jiri Vanek <jvanek at redhat.com>
>
> Allowed signed appletes in automatic reproducers tests
> * tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.html:
> html file for lunching signed applet. Its stile is different from the one for
> calling unsigned applets.

There are a few typos, it should be:

     html file for launching signed applet. It still is different from the one for
     calling unsigned applets.

> * tests/jnlp_tests/signed/AppletTestSigned/resources/bd.css: style of signed
> applets page
> * tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.jnlp:
> jnlp fiel for lunched signed applet

s/fiel/file/

> * tests/jnlp_tests/signed/AppletTestSigned/srcs/AppletTestSigned.java
> body of signed applet
> * tests/jnlp_tests/signed/AppletTestSigned/testcases/AppletTestSignedTests.java:
> (AppletTestSignedTest) testing method to launch signed applet in javaws
> (AppletTestSignedFirefoxTest) testing method to launch signed applet in
> browser
> * Makefile.am: KEYSTORE_PASS, EXPORTED_CERT, TEST_CERT_ALIAS, PUBLIC_KEYSTORE
> PUBLIC_PASS: new globnal variables holding keystores credentials

s/globnal/global/ && s/keystores/keystore/ (or store's, both work)

> (clean-local) clean-bootstrap-directory moved to be last one, as keytool
> is necessary for removing certificate
> (EXPORTED_CERT): new target exporting certificate from testing keystore
> (stamps/netx-dist-tests-import-cert-to-public) new target to
> certificate to PUBLIC_KEYSTORE
> (netx-dist-tests-remove-cert-from-public) new target removing testing
> certificate from PUBLIC_KEYSTORE
> (clean-netx-dist-tests) now depends on netx-dist-tests-remove-cert-from-public
> and is removing EXPORTED_CERT file

You missed a few ":" chars after the braces.

 > diff -r cde6d59a2901 Makefile.am
 > --- a/Makefile.am	Thu Apr 05 10:57:16 2012 -0400
 > +++ b/Makefile.am	Wed Apr 11 11:32:36 2012 +0200
 > @@ -23,6 +23,12 @@
 >   JNLP_TESTS_SERVER_DEPLOYDIR=$(TESTS_DIR)/jnlp_test_server
 >   JNLP_TESTS_DIR=$(TESTS_DIR)/jnlp_tests
 >   KEYSTORE_NAME=teststore.ks
 > +KEYSTORE_PASS=123456789

I'm curious, why was this password chosen over the regular "changeit"? I know that you're getting it from below but I'm wondering if 
anyone knows why the original dev chose this over the normal one. I would rather it be "changeit" for consistency's sake though. What 
do you think?

 > +EXPORTED_CERT=icedteatests.crt
 > +TEST_CERT_ALIAS=icedteaweb
 > +PUBLIC_KEYSTORE=~/.icedtea/security/trusted.certs
 > +PUBLIC_PASS=changeit
 > +

[snip]

 > diff -r cde6d59a2901 tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.html
 > --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
 > +++ b/tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.html	Wed Apr 11 11:32:36 2012 +0200

Heh, nice failure message. ;) It's because the applet was eventually killed, right?

I'm worried that such a harsh failure message will throw testers off, they may not realize it is meant to fail to run. Thoughts? It 
might be useful to add a "(This applet was killed, it should not be running)" message too?

[snip]

diff -r cde6d59a2901 tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.html
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.html	Wed Apr 11 11:32:36 2012 +0200
[...]
 > +<vendor>NetX</vendor>
 > +<homepage href="http://jnlp.sourceforge.net/netx/"/>

Please change these to use IcedTea and the test page[1], thanks.

[snip]

 > diff -r cde6d59a2901 tests/jnlp_tests/signed/AppletTestSigned/resources/bd.css
 > --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
 > +++ b/tests/jnlp_tests/signed/AppletTestSigned/resources/bd.css	Wed Apr 11 11:32:36 2012 +0200

Shouldn't this have a copyright header too? Otherwise if it's easier, you can include it directly in the HTML file instead of a new file.

[snip]

 > diff -r cde6d59a2901 tests/jnlp_tests/signed/AppletTestSigned/srcs/AppletTestSigned.java
 > --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
 > +++ b/tests/jnlp_tests/signed/AppletTestSigned/srcs/AppletTestSigned.java	Wed Apr 11 11:32:36 2012 +0200
 > @@ -0,0 +1,82 @@
 > +
 > +import java.applet.Applet;
 > +
 > +/* AppletTestSigned.java
 > +Copyright (C) 2011 Red Hat, Inc.

s/2011/2012/


[snip]

 > diff -r cde6d59a2901 tests/jnlp_tests/signed/AppletTestSigned/testcases/AppletTestSignedTests.java
 > --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
 > +++ b/tests/jnlp_tests/signed/AppletTestSigned/testcases/AppletTestSignedTests.java	Wed Apr 11 11:32:36 2012 +0200
 > @@ -0,0 +1,100 @@
 > +/* AppletTestTests.java
 > +Copyright (C) 2011 Red Hat, Inc.

s/2011/2012/

[snip]

 > +        Assert.assertTrue("AppletTestSigned stdout should contains " + s3 + " bud didn't", pr.stdout.contains(s3));
 > +        String s0 = "AppletTestSigned was started";
 > +        Assert.assertTrue("AppletTestSigned stdout should contains " + s0 + " bud didn't", pr.stdout.contains(s0));
 > +        String s1 = "value1";
 > +        Assert.assertTrue("AppletTestSigned stdout should contains " + s1 + " bud didn't", pr.stdout.contains(s1));
 > +        String s2 = "value2";
 > +        Assert.assertTrue("AppletTestSigned stdout should contains " + s2 + " bud didn't", pr.stdout.contains(s2));
 > +        String s4 = "AppletTestSigned was stopped";
 > +        Assert.assertFalse("AppletTestSigned stdout shouldn't contains " + s4 + " bud did", pr.stdout.contains(s4));
 > +        String s5 = "AppletTestSigned will be destroyed";
 > +        Assert.assertFalse("AppletTestSigned stdout shouldn't contains " + s5 + " bud did", pr.stdout.contains(s5));
 > +        String ss = "xception";
 > +        Assert.assertFalse("AppletTestSigned stderr should not contains " + ss + " but did", pr.stderr.contains(ss));

For "AppletTestSigned stdout should contains ", s/ contains / contain / (without the s). Also s/bud/but/ =)

Everything else looks good! Thanks for getting this done.

Cheers,
Danesh

[1] http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Web


From andrew at icedtea.classpath.org  Wed Apr 11 13:19:40 2012
From: andrew at icedtea.classpath.org (andrew at icedtea.classpath.org)
Date: Wed, 11 Apr 2012 20:19:40 +0000
Subject: /hg/icedtea7: Fix build on GCC 4.7.
Message-ID: <hg.887110bdf826.1334175580.2873452341184383833@icedtea.classpath.org>

changeset 887110bdf826 in /hg/icedtea7
details: http://icedtea.classpath.org/hg/icedtea7?cmd=changeset;node=887110bdf826
author: Andrew John Hughes <ahughes at redhat.com>
date: Wed Apr 11 21:19:33 2012 +0100

	Fix build on GCC 4.7.

	2012-04-11  Andrew John Hughes  <ahughes at redhat.com>

		* Makefile.am:
		(JDK_CHANGESET): Bump to include GCC 4.7 build fixes.
		(JDK_SHA256SUM): Likewise.


diffstat:

 ChangeLog   |  6 ++++++
 Makefile.am |  4 ++--
 2 files changed, 8 insertions(+), 2 deletions(-)

diffs (34 lines):

diff -r 2c3f32cee817 -r 887110bdf826 ChangeLog
--- a/ChangeLog	Wed Apr 11 18:36:03 2012 +0100
+++ b/ChangeLog	Wed Apr 11 21:19:33 2012 +0100
@@ -1,3 +1,9 @@
+2012-04-11  Andrew John Hughes  <ahughes at redhat.com>
+
+	* Makefile.am:
+	(JDK_CHANGESET): Bump to include GCC 4.7 build fixes.
+	(JDK_SHA256SUM): Likewise.
+
 2012-04-11  Andrew John Hughes  <ahughes at redhat.com>
 
 	* Makefile.am:
diff -r 2c3f32cee817 -r 887110bdf826 Makefile.am
--- a/Makefile.am	Wed Apr 11 18:36:03 2012 +0100
+++ b/Makefile.am	Wed Apr 11 21:19:33 2012 +0100
@@ -8,7 +8,7 @@
 HOTSPOT_CHANGESET = b1dfb460ee5c
 JAXP_CHANGESET = 9b7a2f21b8a8
 JAXWS_CHANGESET = 9ae185bd7ff2
-JDK_CHANGESET = a1fe26be9fab
+JDK_CHANGESET = 1aea8312412a
 LANGTOOLS_CHANGESET = 54b1383d794c
 OPENJDK_CHANGESET = 3a0fd3cc84a0
 
@@ -16,7 +16,7 @@
 HOTSPOT_SHA256SUM = 43d83d5209a9f748e6650c792ca8ef8d9a90d6e3c53e461993c6bffb8c37e972
 JAXP_SHA256SUM = 4d38e8a0fc0fcbe3ba8a56f9fc0960ecbf15cd4cef44b76fdc82418c008a33c3
 JAXWS_SHA256SUM = 60c6c62c851eafc15ff33e58aa625e6f58fd31f15328b121602a07891fc1d272
-JDK_SHA256SUM = 8455cc8888eaaba420a0a37ed1d76b73b7b67dcade3c856626f9ce82e1fc2408
+JDK_SHA256SUM = 1d5f1b7a5d9f8be06105130aa1c0f1898e9b91fb8d968d7ccb21d2b365575802
 LANGTOOLS_SHA256SUM = 97821e49028d8d726fac9563c361c682146e037074179cbd68ed5cb80e82f9fa
 OPENJDK_SHA256SUM = abe0c3b348c35f79117ef726bb2580b279024b1f73b6487fda4a1e717c738f9f
 


From jvanek at redhat.com  Thu Apr 12 01:02:12 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Thu, 12 Apr 2012 10:02:12 +0200
Subject: [rfc][icedtea-web] signed applets test
In-Reply-To: <4F85D38B.6060502@redhat.com>
References: <4F85501C.1080003@redhat.com> <4F85D38B.6060502@redhat.com>
Message-ID: <4F868C04.20301@redhat.com>

On 04/11/2012 08:55 PM, Danesh Dadachanji wrote:
...
>> There is question how to deal with -Xtrustall which is now useless when there is trusted
>> certificate (all signed reproducers are right
>> now signed with same cert, and when more to much reproducers will need to much different
>> certificates this will need re-factoring
>> probably too).
>>
>
> I don't mind -Xtrustall staying, I think it helps for testing stuff on the fly, outside the test
> suite. However, I'm not too strong about this so if you want to remove it, feel free.
>

Yap. I'm for to keep it inside too.

>> After this change is in, the PR905 reproducer have sense to go in too.
>>
>
> +1
>
>> changelog:
...
> There are a few typos, it should be:
>

fixed .. I hope...

>  > diff -r cde6d59a2901 Makefile.am
>  > --- a/Makefile.am Thu Apr 05 10:57:16 2012 -0400
>  > +++ b/Makefile.am Wed Apr 11 11:32:36 2012 +0200
>  > @@ -23,6 +23,12 @@
>  > JNLP_TESTS_SERVER_DEPLOYDIR=$(TESTS_DIR)/jnlp_test_server
>  > JNLP_TESTS_DIR=$(TESTS_DIR)/jnlp_tests
>  > KEYSTORE_NAME=teststore.ks
>  > +KEYSTORE_PASS=123456789
>
> I'm curious, why was this password chosen over the regular "changeit"? I know that you're getting it
> from below but I'm wondering if anyone knows why the original dev chose this over the normal one. I
> would rather it be "changeit" for consistency's sake though. What do you think?
>
>  > +EXPORTED_CERT=icedteatests.crt
>  > +TEST_CERT_ALIAS=icedteaweb
>  > +PUBLIC_KEYSTORE=~/.icedtea/security/trusted.certs
>  > +PUBLIC_PASS=changeit
>  > +
>
> [snip]
>
>  > diff -r cde6d59a2901 tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.html
>  > --- /dev/null Thu Jan 01 00:00:00 1970 +0000
>  > +++ b/tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.html Wed Apr 11
> 11:32:36 2012 +0200
>
> Heh, nice failure message. ;) It's because the applet was eventually killed, right?
>
> I'm worried that such a harsh failure message will throw testers off, they may not realize it is
> meant to fail to run. Thoughts? It might be useful to add a "(This applet was killed, it should not
> be running)" message too?

nn - First reason was to distinguish normal applet's page/signed applet's page, then I got evil 
mind, some nice memories to blue death remembered 1.4, and result was this  distinguisher :)

I have removed it, and restoree original red. This was putting to big effort for test-writers. 
However, this can be isnpiration for feature ;)
>
> [snip]
>
> diff -r cde6d59a2901 tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.html
> --- /dev/null Thu Jan 01 00:00:00 1970 +0000
> +++ b/tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.html Wed Apr 11 11:32:36
> 2012 +0200
> [...]
>  > +<vendor>NetX</vendor>
>  > +<homepage href="http://jnlp.sourceforge.net/netx/"/>
>
> Please change these to use IcedTea and the test page[1], thanks.
>
grrr. Done. Thanx for warning.
> [snip]
>
>  > diff -r cde6d59a2901 tests/jnlp_tests/signed/AppletTestSigned/resources/bd.css
>  > --- /dev/null Thu Jan 01 00:00:00 1970 +0000
>  > +++ b/tests/jnlp_tests/signed/AppletTestSigned/resources/bd.css Wed Apr 11 11:32:36 2012 +0200
>
> Shouldn't this have a copyright header too? Otherwise if it's easier, you can include it directly in
> the HTML file instead of a new file.

I n case blue death like  message will go in, then it definitely will be good idea to have separate 
css file and so not to write it again and again...
>
> [snip]
>
>  > diff -r cde6d59a2901 tests/jnlp_tests/signed/AppletTestSigned/srcs/AppletTestSigned.java
>  > --- /dev/null Thu Jan 01 00:00:00 1970 +0000
>  > +++ b/tests/jnlp_tests/signed/AppletTestSigned/srcs/AppletTestSigned.java Wed Apr 11 11:32:36
> 2012 +0200
>  > @@ -0,0 +1,82 @@
>  > +
>  > +import java.applet.Applet;
>  > +
>  > +/* AppletTestSigned.java
>  > +Copyright (C) 2011 Red Hat, Inc.
>
> s/2011/2012/
>
>
> [snip]
>
>  > diff -r cde6d59a2901 tests/jnlp_tests/signed/AppletTestSigned/testcases/AppletTestSignedTests.java
>  > --- /dev/null Thu Jan 01 00:00:00 1970 +0000
>  > +++ b/tests/jnlp_tests/signed/AppletTestSigned/testcases/AppletTestSignedTests.java Wed Apr 11
> 11:32:36 2012 +0200
>  > @@ -0,0 +1,100 @@
>  > +/* AppletTestTests.java
>  > +Copyright (C) 2011 Red Hat, Inc.
>
> s/2011/2012/
>
> [snip]
>
>  > + Assert.assertTrue("AppletTestSigned stdout should contains " + s3 + " bud didn't",
> pr.stdout.contains(s3));
>  > + String s0 = "AppletTestSigned was started";
>  > + Assert.assertTrue("AppletTestSigned stdout should contains " + s0 + " bud didn't",
> pr.stdout.contains(s0));
>  > + String s1 = "value1";
>  > + Assert.assertTrue("AppletTestSigned stdout should contains " + s1 + " bud didn't",
> pr.stdout.contains(s1));
>  > + String s2 = "value2";
>  > + Assert.assertTrue("AppletTestSigned stdout should contains " + s2 + " bud didn't",
> pr.stdout.contains(s2));
>  > + String s4 = "AppletTestSigned was stopped";
>  > + Assert.assertFalse("AppletTestSigned stdout shouldn't contains " + s4 + " bud did",
> pr.stdout.contains(s4));
>  > + String s5 = "AppletTestSigned will be destroyed";
>  > + Assert.assertFalse("AppletTestSigned stdout shouldn't contains " + s5 + " bud did",
> pr.stdout.contains(s5));
>  > + String ss = "xception";
>  > + Assert.assertFalse("AppletTestSigned stderr should not contains " + ss + " but did",
> pr.stderr.contains(ss));
>
> For "AppletTestSigned stdout should contains ", s/ contains / contain / (without the s). Also
> s/bud/but/ =)

All above should e fixed. Thanx for review!

>
> Everything else looks good! Thanks for getting this done.
>
> Cheers,
> Danesh
>
> [1] http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Web

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signedApplets2.diff
Type: text/x-patch
Size: 19122 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120412/f19dd85f/signedApplets2.diff 

From jvanek at redhat.com  Thu Apr 12 05:05:23 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Thu, 12 Apr 2012 14:05:23 +0200
Subject: [rfc] [icedtea-web] blacklist for reproducers
In-Reply-To: <4F8453FA.2040606@redhat.com>
References: <4F7EE803.4060401@redhat.com> <4F8217B4.7050308@redhat.com>
	<4F841CB8.9000004@redhat.com> <4F8453FA.2040606@redhat.com>
Message-ID: <4F86C503.80700@redhat.com>

> [ snip lots of analysis ]

So here is my suggestion, why so, see inline below. Namely the changes are:
* jnlp_testengine renamed to testsExtensions, and remains in tests directory
* all tests from jnlp_testengine are dedicated to tests/testsExtensionsTests
* testsExtensions I would like to pack into junit-runner.jar
* directory jnlp_tests have been renamed to reproducers and moved from tests to tests/netx
==:


??? extra
?   ??? net
?       ??? sourceforge
?           ??? javaws
?               ??? about
?                   ??? resources
??? launcher
??? netx
?   ??? javax
?   ?   ??? jnlp
?   ??? net
?       ??? sourceforge
?           ??? jnlp
...
?           ??? nanoxml
??? plugin
?   ??? docs
?   ??? icedteanp
?   ?   ??? java
...
?   ??? tests
?       ??? LiveConnect
??? tests
     ??? junit-runner
     ??? netx
     ?   ??? pac
     ?   ??? reproducers
     ?   ?   ??? signed
...
     ?   ?   ??? simple
...
     ?   ??? unit
     ?       ??? net
     ?           ??? sourceforge
     ?               ??? jnlp
...
     ??? report-styles
     ??? testsExtensions
     ?   ??? net
     ?       ??? sourceforge
     ?           ??? jnlp
     ??? testsExtensionsTests
         ??? net
             ??? sourceforge
                 ??? jnlp

> And I agree; jnlp_testengine contains too much and does not really
> belong there.
Yap I have renamed it to testsExtensions (or tests-extensions?) For now this extension is just 
virtual server and few util methods, But with eg [1] or [2] there will be little bit more, and there 
always can be more extensions necessary in future.
>
>> 1) move all tests from tests/netx/jnlp_testsengine to tests/netx/unit
>> where they belongs IMHO
>
> A slightly different approach might be to move jnlp_testsengine itself
> to a top level directory in icedtea-web.

Hmhm. I'm against top level directory. Overall - it is still just for testing, so it should stay in 
tests. Also there is eg junit-runner in tests. Those two subdirectories (junit-runner and 
testsExtensions)  should be on same level.
>jnlp_testsengine isn't a test
> itself so I would be happy if we moved it out from under tests/. I dont
> think moving the tests from tests/netx/jnlp_testsengine to
> tests/netx/unit is a good idea; they are not netx's tests. How about
> creating another directory (jnlp_testengine under tests/) to contain
> tests for the jnlp_engine itself? (which are distinct from netx's or the
> plugin's tests).
Aboslutly agree:)
So what about testsExtensionsTests (or tests-extensions-tests) on same level as netx (which contains 
unittests and  pactests (and I would like to/I have  move(d) reproducers into here) and styles and 
junit-runne rand testsExtensions?

but - when to run content of testsExtensionsTests? I would like to include it inside netx unit test 
(or let it in netx reproducers tests run as it is now) rather then run special tests-run for them.
>
>> 1.5) With this refactoring I would like to extract all inner classes
>> from ServerAccess
>
> +1 from me
>
>> 2) fix compile and runtime class-path of unittests for
>> tests/netx/jnlp_testsengine
>
> This sounds fine.
>
>> 3) during reproducers run launch *just* compiled testcases
>
> Could you clarify what you mean here?
Right now also classes which are not "test-calses" (eg everything under jnlp_testengine) are 
launched. It is definietly wrong. Some of this will be easily fixed by this refactoring, but some 
issues can remain.
>
>> 4) no more tests in tests/netx/jnlp_testsengine, framework will be
>> tested in unittests (same as (1) but just for ensuring..:) )
>
> See my points for 1, then :)
>
>> 4.5) unittets and reprodyucers runs should have same classapth in
>> runtime/compiletime. =>  unify them in some variable(s)(?)
>
> No objections here (if it works, of course; there may be some subtle
> issues).
probably...for sure.. Lets see how I will deal with it :)
>
>> 5) I'm also for adding tests/netx/jnlp_testsengine to compile class-path
>> of junit-runner (as it looks useful from [1,2] point of view.
>
> I haven't seen [1] or [2] yet. But we can consider that separately,
> right? I am not opposed to it - but let's consider that on it's own merits.

Here I have (maybe interesting) idea:
All our java tests are executed from junit-runner classes, which are packed to junit-runner.jar
I would (very!) like to include also all the testsExtensions clases in this jar. It will make the 
unifications of classpaths much more straightforward (and this jar hmhm... can be useful by its cntent)
>
>> 6) Maybe after all of above done the jnlp_testsengine can be renamed and
>> moved somewhere else. (and also jnlp_tests probably should be moved to
>> tests/netx/) But This should be done as separate changeset.
>
> I was going to suggest that myself. +1
..well.. necessary - done somehow by itself alone...
>
>
>For launching just some tests I would like then introduce some whitelist

whitelist will be separate patch..somewhen

>

One moire think is that there is some work in progress - especially browser tests[1] (rigt now 
blocked by make links) and some  minor improvements [2], (and maybe  also signed applets and pr905 
reproducer) which I would like to put inside before this re factoring....But hose steps can 
collaborate ..somehow.
And it will give us(well..me.. I'm the rush one here...:-/) time to think about it.

[1]http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-March/017799.html
[2]http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120320/8ef6bdfe/browserTests-BugAnnotation-0001.diff 


O:)

Best regards J.


From ptisnovs at icedtea.classpath.org  Thu Apr 12 05:56:38 2012
From: ptisnovs at icedtea.classpath.org (ptisnovs at icedtea.classpath.org)
Date: Thu, 12 Apr 2012 12:56:38 +0000
Subject: /hg/gfx-test: * src/org/gfxtest/ImageDiffer/Main.java:
Message-ID: <hg.4a4eb075c03f.1334235398.-6248649288953172555@icedtea.classpath.org>

changeset 4a4eb075c03f in /hg/gfx-test
details: http://icedtea.classpath.org/hg/gfx-test?cmd=changeset;node=4a4eb075c03f
author: Pavel Tisnovsky <ptisnovs at redhat.com>
date: Thu Apr 12 14:59:12 2012 +0200

	* src/org/gfxtest/ImageDiffer/Main.java:
		* src/org/gfxtest/framework/annotations/GraphicsPrimitive.java:
		* src/org/gfxtest/framework/annotations/GraphicsPrimitives.java:
		* src/org/gfxtest/framework/annotations/RenderStyle.java:
		* src/org/gfxtest/framework/annotations/RenderStyles.java:
		* src/org/gfxtest/framework/annotations/TestType.java:
		* src/org/gfxtest/framework/annotations/TestTypes.java:
		* src/org/gfxtest/framework/annotations/Transformation.java:
		* src/org/gfxtest/framework/annotations/Transformations.java:
		Code and JavaDoc improvements.


diffstat:

 ChangeLog                                                     |  13 +++++++++++
 src/org/gfxtest/ImageDiffer/Main.java                         |   4 ++-
 src/org/gfxtest/framework/annotations/GraphicsPrimitive.java  |   1 +
 src/org/gfxtest/framework/annotations/GraphicsPrimitives.java |   1 +
 src/org/gfxtest/framework/annotations/RenderStyle.java        |   1 +
 src/org/gfxtest/framework/annotations/RenderStyles.java       |   1 +
 src/org/gfxtest/framework/annotations/TestType.java           |   1 +
 src/org/gfxtest/framework/annotations/TestTypes.java          |   1 +
 src/org/gfxtest/framework/annotations/Transformation.java     |   1 +
 src/org/gfxtest/framework/annotations/Transformations.java    |   6 +++++
 10 files changed, 29 insertions(+), 1 deletions(-)

diffs (139 lines):

diff -r 0594d3a7c745 -r 4a4eb075c03f ChangeLog
--- a/ChangeLog	Fri Apr 06 13:03:55 2012 +0200
+++ b/ChangeLog	Thu Apr 12 14:59:12 2012 +0200
@@ -1,3 +1,16 @@
+2012-04-12  Pavel Tisnovsky  <ptisnovs at redhat.com>
+
+	* src/org/gfxtest/ImageDiffer/Main.java:
+	* src/org/gfxtest/framework/annotations/GraphicsPrimitive.java:
+	* src/org/gfxtest/framework/annotations/GraphicsPrimitives.java:
+	* src/org/gfxtest/framework/annotations/RenderStyle.java:
+	* src/org/gfxtest/framework/annotations/RenderStyles.java:
+	* src/org/gfxtest/framework/annotations/TestType.java:
+	* src/org/gfxtest/framework/annotations/TestTypes.java:
+	* src/org/gfxtest/framework/annotations/Transformation.java:
+	* src/org/gfxtest/framework/annotations/Transformations.java:
+	Code and JavaDoc improvements.
+
 2012-04-05  Pavel Tisnovsky  <ptisnovs at redhat.com>
 
 	* src/org/gfxtest/common/Configuration.java:
diff -r 0594d3a7c745 -r 4a4eb075c03f src/org/gfxtest/ImageDiffer/Main.java
--- a/src/org/gfxtest/ImageDiffer/Main.java	Fri Apr 06 13:03:55 2012 +0200
+++ b/src/org/gfxtest/ImageDiffer/Main.java	Thu Apr 12 14:59:12 2012 +0200
@@ -107,7 +107,7 @@
     {
         System.out.println(
                 "Welcome to Lupic, the yet another image comparator\n\n" +
-                "(c) 2010, 2011 Pavel Tisnovsky, Red Hat Inc.\n\n" +
+                "(c) 2010, 2011, 2012 Pavel Tisnovsky, Red Hat Inc.\n\n" +
                 " Usage:\n " +
                 "java -jar lupic.jar -s1=./samples -s2=./output -m=./masks -b=./bitmap-masks -o=./output --html --html-results --xml-results --diff-images --struct-diff-images\n" +
                 "\n" +
@@ -229,6 +229,8 @@
     }
 
     /**
+     * Entry point to this tool.
+     *
      * @param args
      */
     public static void main(String[] args)
diff -r 0594d3a7c745 -r 4a4eb075c03f src/org/gfxtest/framework/annotations/GraphicsPrimitive.java
--- a/src/org/gfxtest/framework/annotations/GraphicsPrimitive.java	Fri Apr 06 13:03:55 2012 +0200
+++ b/src/org/gfxtest/framework/annotations/GraphicsPrimitive.java	Thu Apr 12 14:59:12 2012 +0200
@@ -48,6 +48,7 @@
 /**
  * Declaration of interface used to specify graphics primitive for each test
  * suite.
+ * @see GraphicsPrimitives
  * 
  * @author Pavel Tisnovsky
  */
diff -r 0594d3a7c745 -r 4a4eb075c03f src/org/gfxtest/framework/annotations/GraphicsPrimitives.java
--- a/src/org/gfxtest/framework/annotations/GraphicsPrimitives.java	Fri Apr 06 13:03:55 2012 +0200
+++ b/src/org/gfxtest/framework/annotations/GraphicsPrimitives.java	Thu Apr 12 14:59:12 2012 +0200
@@ -44,6 +44,7 @@
 
 /**
  * Names of graphics primitives used for annotation of each test suite.
+ * @see GraphicsPrimitive
  * 
  * @author Pavel Tisnovsky
  */
diff -r 0594d3a7c745 -r 4a4eb075c03f src/org/gfxtest/framework/annotations/RenderStyle.java
--- a/src/org/gfxtest/framework/annotations/RenderStyle.java	Fri Apr 06 13:03:55 2012 +0200
+++ b/src/org/gfxtest/framework/annotations/RenderStyle.java	Thu Apr 12 14:59:12 2012 +0200
@@ -47,6 +47,7 @@
 
 /**
  * Interface declaration for specifying render style used by test suites.
+ * @see RenderStyles
  * 
  * @author Pavel Tisnovsky
  */
diff -r 0594d3a7c745 -r 4a4eb075c03f src/org/gfxtest/framework/annotations/RenderStyles.java
--- a/src/org/gfxtest/framework/annotations/RenderStyles.java	Fri Apr 06 13:03:55 2012 +0200
+++ b/src/org/gfxtest/framework/annotations/RenderStyles.java	Thu Apr 12 14:59:12 2012 +0200
@@ -42,6 +42,7 @@
 
 /**
  * Render styles used by particular test suite.
+ * @see RenderStyle
  * 
  * @author Pavel Tisnovsky
  */
diff -r 0594d3a7c745 -r 4a4eb075c03f src/org/gfxtest/framework/annotations/TestType.java
--- a/src/org/gfxtest/framework/annotations/TestType.java	Fri Apr 06 13:03:55 2012 +0200
+++ b/src/org/gfxtest/framework/annotations/TestType.java	Thu Apr 12 14:59:12 2012 +0200
@@ -48,6 +48,7 @@
 /**
  * Declaration of annotation which can be used to select type of the graphics
  * test suite.
+ * @see TestTypes
  * 
  * @author Pavel Tisnovsky
  */
diff -r 0594d3a7c745 -r 4a4eb075c03f src/org/gfxtest/framework/annotations/TestTypes.java
--- a/src/org/gfxtest/framework/annotations/TestTypes.java	Fri Apr 06 13:03:55 2012 +0200
+++ b/src/org/gfxtest/framework/annotations/TestTypes.java	Thu Apr 12 14:59:12 2012 +0200
@@ -44,6 +44,7 @@
 
 /**
  * Type of the graphics test suite.
+ * @see TestType
  * 
  * @author Pavel Tisnovsky
  */
diff -r 0594d3a7c745 -r 4a4eb075c03f src/org/gfxtest/framework/annotations/Transformation.java
--- a/src/org/gfxtest/framework/annotations/Transformation.java	Fri Apr 06 13:03:55 2012 +0200
+++ b/src/org/gfxtest/framework/annotations/Transformation.java	Thu Apr 12 14:59:12 2012 +0200
@@ -47,6 +47,7 @@
 
 /**
  * Transformation used for particular rendering test.
+ * @see Transformations
  * 
  * @author Pavel Tisnovsky
  */
diff -r 0594d3a7c745 -r 4a4eb075c03f src/org/gfxtest/framework/annotations/Transformations.java
--- a/src/org/gfxtest/framework/annotations/Transformations.java	Fri Apr 06 13:03:55 2012 +0200
+++ b/src/org/gfxtest/framework/annotations/Transformations.java	Thu Apr 12 14:59:12 2012 +0200
@@ -44,6 +44,7 @@
 
 /**
  * Transformation used for particular rendering test.
+ * @see Transformation
  * 
  * @author Pavel Tisnovsky
  */
@@ -68,4 +69,9 @@
      * Mirror linear transformation is used.
      */
     MIRROR,
+
+    /**
+     * Skew linear transformation is used.
+     */
+    SKEW,
 }


From jvanek at redhat.com  Thu Apr 12 06:11:17 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Thu, 12 Apr 2012 15:11:17 +0200
Subject: RFC - Reduce loading of PropertiesFile
In-Reply-To: <1334087640.1431.26.camel@localhost.localdomain>
References: <1334087640.1431.26.camel@localhost.localdomain>
Message-ID: <4F86D475.5020202@redhat.com>

Hi!

diffs as attachments and changelogs as plaintext please :)

Idea looks excelent, but several issues inline:

On 04/10/2012 09:54 PM, Thomas Meyer wrote:
> diff -r 60ef5191add3 netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java
> --- a/netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java	Tue Apr 10 19:10:43 2012 +0200
> +++ b/netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java	Tue Apr 10 21:49:08 2012 +0200
> @@ -108,11 +108,11 @@
>        * Update map for keeping track of recently used items.
>        */
>       public synchronized void load() {
> -        cacheOrder.load();
> +        boolean loaded = cacheOrder.load();
>           /*
>            * clean up possibly corrupted entries
>            */
> -        if (checkData()) {
> +        if (loaded == true&&  checkData()) {
+        if (loaded && checkData()) {
please ;)
(unless it somehow destroy difference between && and & O:) )

>               if (JNLPRuntime.isDebug()) {
>                   new LruCacheException().printStackTrace();
>               }
> @@ -125,7 +125,7 @@
>       /**
>        * check content of cacheOrder and remove invalid/corrupt entries
>        *
> -     * @return true, if cache was coruupted and affected entry removed
> +     * @return true, if cache was corrupted and affected entry removed
>        */
>       private boolean checkData () {
>           boolean modified = false;
> diff -r 60ef5191add3 netx/net/sourceforge/jnlp/util/PropertiesFile.java
> --- a/netx/net/sourceforge/jnlp/util/PropertiesFile.java	Tue Apr 10 19:10:43 2012 +0200
> +++ b/netx/net/sourceforge/jnlp/util/PropertiesFile.java	Tue Apr 10 21:49:08 2012 +0200
> @@ -35,6 +35,9 @@
>
>       /** the header string */
>       String header = "netx file";
> +
> +    /** time of last modification */
> +    long lastStore;
>
>       /** lazy loaded on getProperty */
>       boolean loaded = false;
> @@ -104,24 +107,32 @@
>        * Ensures that the file backing these properties has been
>        * loaded; call this method before calling any method defined by
>        * a superclass.
> +     *
> +     * @return true, if file was (re-)loaded
> +     *         false, if file was still current
>        */
> -    public void load() {
> +    public boolean load() {
>           loaded = true;
Looks like unused?
>
> -        InputStream s = null;
> -        try {
this
> -            if (!file.exists())
> -                return;
should remains here, returning false, as you are testing file.lastModified() later

> +        if(lastStore == 0 || lastStore>  0&&  file.lastModified() != lastStore) {
I believe this lastStore>  0 is redudat:
if(lastStore == 0 || file.lastModified() != lastStore)
will do the same thing?

> +            InputStream s = null;
> +            try {
this
> +                if (!file.exists())
> +                    return false;
will be redundant then (^^^)
> +
> +                try {
> +                    s = new FileInputStream(file);
When you are touching this, I believe the encoding of this file should be during storing and loading 
namely specified as utf-8 (icedtea-web have issues with encodings... so its better to start sooner 
then later)
> +                    load(s);
       *1 (see below ;)
> +                } finally {
> +                    if (s != null) s.close();
> +                }
> +            } catch (IOException ex) {
> +                ex.printStackTrace();
return false here?
> +            }
> +            return true;
no return here here
> +        }
>
> -            try {
> -                s = new FileInputStream(file);
> -                load(s);
> -            } finally {
> -                if (s != null) s.close();
> -            }
> -        } catch (IOException ex) {
> -            ex.printStackTrace();
> -        }
> +        return false;
shouldn't  there be return true/nothing (returns already solved) - considering my hints are valid?
>       }
>
>       /**
> @@ -137,6 +148,7 @@
>                   file.getParentFile().mkdirs();
>                   s = new FileOutputStream(file);
>                   store(s, header);
> +                lastStore = file.lastModified();
This is shouldn't be there. I would like to move lastStore = file.lastModified(); to load function. 
or  to "*1" location (because reason of this timestamp is also external modification of recently_used)
>               } finally {
>                   if (s != null) s.close();
>               }
>
>
Little bit of-the-basin think - are you sure that store() as it is written changes lastModified() 
linux stamp correctly? (I had some bad experiences with this, but have never examined it separately)

Also I would like to suggest at least two tests with this patch
1) generate eg 1mb recently_used file and measure set some deadline how fast javaws  have to start. 
   The value should be failing without this patch, and  passing with this one applied. Also some 
real number how faster this is will be much appreciate!

2) second one will be little bit more difficult. It would be nice to test, that when recently_used 
is modified during javaws run, then it reloads it correctly. And so verify that this patch will not 
cause some regression.


Maybe unittest will be easier to prepare instead of 2)
But I'm afraid those (or similar ) tests will be really necessary.


What do you think?



btw - there is task[1] which have long-term goal to rewrite cache subsystem. Do you want to be 
volunteer?

Thanx for the patch!
Best regards
    J.

[1] http://icedtea.classpath.org/wiki/IcedTea-Web - Caching subsystem replacement assigned to guru 
Omair (omajid at redhat.com)



From omajid at redhat.com  Thu Apr 12 09:39:01 2012
From: omajid at redhat.com (Omair Majid)
Date: Thu, 12 Apr 2012 12:39:01 -0400
Subject: [rfc] [icedtea-web] blacklist for reproducers
In-Reply-To: <4F86C503.80700@redhat.com>
References: <4F7EE803.4060401@redhat.com> <4F8217B4.7050308@redhat.com>
	<4F841CB8.9000004@redhat.com> <4F8453FA.2040606@redhat.com>
	<4F86C503.80700@redhat.com>
Message-ID: <4F870525.2000308@redhat.com>

On 04/12/2012 08:05 AM, Jiri Vanek wrote:
>> [ snip lots of analysis ]

So I am going to preface this email by pointing out that I like the
overall change that you are proposing. Most of my
arguments/disagreements/suggestions are about minute details. Perhaps
you should just ignore them :)

> So here is my suggestion, why so, see inline below. Namely the changes are:
> * jnlp_testengine renamed to testsExtensions, and remains in tests
> directory

This is probably going into the area of bikeshedding, but I feel the
current name is better. Looking at existing names, I would be happy with
jnlp-test-engine (jnlp-test-runner, or maybe even jnlp-runner).

> * all tests from jnlp_testengine are dedicated to
> tests/testsExtensionsTests

I am guessing you meant 'moved'.

> * testsExtensions I would like to pack into junit-runner.jar

Is this necessary? I would like to keep them separate. When I originally
wrote the code for junit-runner (licensed under CPL), I intentionally
kept it separate from the rest of the (L)GPL(+Classpath) code.

> * directory jnlp_tests have been renamed to reproducers and moved from
> tests to tests/netx

Sounds fantastic!

>> And I agree; jnlp_testengine contains too much and does not really
>> belong there.
> Yap I have renamed it to testsExtensions (or tests-extensions?) For now
> this extension is just virtual server and few util methods, But with eg
> [1] or [2] there will be little bit more, and there always can be more
> extensions necessary in future.

Hm.. I don't know what's the right thing to do here. But I feel like
extensions for testing (that is, extra annotations, utility methods)
should be kept separate from the test engine (which just runs tests).

>>
>>> 1) move all tests from tests/netx/jnlp_testsengine to tests/netx/unit
>>> where they belongs IMHO
>>
>> A slightly different approach might be to move jnlp_testsengine itself
>> to a top level directory in icedtea-web.
> 
> Hmhm. I'm against top level directory. Overall - it is still just for
> testing, so it should stay in tests. Also there is eg junit-runner in
> tests. Those two subdirectories (junit-runner and testsExtensions) 
> should be on same level.

My reasoning for moving it to a top level directory is that it needs
tests, while junit-runner doesn't :)

>> jnlp_testsengine isn't a test
>> itself so I would be happy if we moved it out from under tests/. I dont
>> think moving the tests from tests/netx/jnlp_testsengine to
>> tests/netx/unit is a good idea; they are not netx's tests. How about
>> creating another directory (jnlp_testengine under tests/) to contain
>> tests for the jnlp_engine itself? (which are distinct from netx's or the
>> plugin's tests).
> Aboslutly agree:)
> So what about testsExtensionsTests (or tests-extensions-tests) on same
> level as netx (which contains unittests and  pactests (and I would like
> to/I have  move(d) reproducers into here) and styles and junit-runne
> rand testsExtensions?

I agree that testsExtensionTests (can we have a better name, please?)
should be in the same level as netx.

> but - when to run content of testsExtensionsTests? I would like to
> include it inside netx unit test (or let it in netx reproducers tests
> run as it is now) rather then run special tests-run for them.

I think it would make sense to run it when we build jnlp_testengine.
This ensure that the jnlp_testengine just built works as expected.


>>> 3) during reproducers run launch *just* compiled testcases
>>
>> Could you clarify what you mean here?
> Right now also classes which are not "test-calses" (eg everything under
> jnlp_testengine) are launched. It is definietly wrong. Some of this will
> be easily fixed by this refactoring, but some issues can remain.

Ah. so by "just" you meant "only" (as opposed to what just means in the
acronym JIT). Makes complete sense now :)


> Here I have (maybe interesting) idea:
> All our java tests are executed from junit-runner classes, which are
> packed to junit-runner.jar
> I would (very!) like to include also all the testsExtensions clases in
> this jar. It will make the unifications of classpaths much more
> straightforward (and this jar hmhm... can be useful by its cntent)

Please see my note about about mixing the CPL licensed code with other
things.

Cheers,
Omair


From jvanek at redhat.com  Thu Apr 12 10:37:18 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Thu, 12 Apr 2012 19:37:18 +0200
Subject: [rfc] [icedtea-web] blacklist for reproducers
In-Reply-To: <4F870525.2000308@redhat.com>
References: <4F7EE803.4060401@redhat.com> <4F8217B4.7050308@redhat.com>
	<4F841CB8.9000004@redhat.com> <4F8453FA.2040606@redhat.com>
	<4F86C503.80700@redhat.com> <4F870525.2000308@redhat.com>
Message-ID: <4F8712CE.1010502@redhat.com>

On 04/12/2012 06:39 PM, Omair Majid wrote:
> On 04/12/2012 08:05 AM, Jiri Vanek wrote:
>>> [ snip lots of analysis ]
>
> So I am going to preface this email by pointing out that I like the
> overall change that you are proposing. Most of my
> arguments/disagreements/suggestions are about minute details. Perhaps
> you should just ignore them :)
>
>> So here is my suggestion, why so, see inline below. Namely the changes are:
>> * jnlp_testengine renamed to testsExtensions, and remains in tests
>> directory
>
> This is probably going into the area of bikeshedding, but I feel the
> current name is better. Looking at existing names, I would be happy with
> jnlp-test-engine (jnlp-test-runner, or maybe even jnlp-runner).
>
But this is not true. The runner is still junit-runner and nothing else.
The content of jnlp_testengine is currently nothing more then dummy implementation of http server, and set of methods which make work with this server easy.
And what is it else then junit extension, if it set of util methods for running this server executing process, wrapping those two into launching some jnlp/html file upon this server in javaws/browser process?
And if some more functionalities (annotations in short term) will come, then it will be more and more set of..."extensions"... then just engine launching jnlp files.
Another issue here is that also html files are launched now. I would like (at least)  to get rid of jnlp from name.
Yes, this is bikeshedding but i do not want to make some more refactoring in close future.
But it does not mean i like my suggested name to much;)
>> * all tests from jnlp_testengine are dedicated to
>> tests/testsExtensionsTests
>
> I am guessing you meant 'moved'.
>
>> * testsExtensions I would like to pack into junit-runner.jar
>
> Is this necessary? I would like to keep them separate. When I originally
no. Just comfortable :)
> wrote the code for junit-runner (licensed under CPL), I intentionally
> kept it separate from the rest of the (L)GPL(+Classpath) code.

Yap. I have forgot of this license issue. I will stay away from merging this two packages together then.

>
>> * directory jnlp_tests have been renamed to reproducers and moved from
>> tests to tests/netx
>
> Sounds fantastic!
>
>>> And I agree; jnlp_testengine contains too much and does not really
>>> belong there.
>> Yap I have renamed it to testsExtensions (or tests-extensions?) For now
>> this extension is just virtual server and few util methods, But with eg
>> [1] or [2] there will be little bit more, and there always can be more
>> extensions necessary in future.
>
> Hm.. I don't know what's the right thing to do here. But I feel like
> extensions for testing (that is, extra annotations, utility methods)
> should be kept separate from the test engine (which just runs tests).
>
And they are. As told above. the test engine (which just runs tests) is junit-runner. jnlp-testengine is right the extension as you mean it.
>>>
>>>> 1) move all tests from tests/netx/jnlp_testsengine to tests/netx/unit
>>>> where they belongs IMHO
>>>
>>> A slightly different approach might be to move jnlp_testsengine itself
>>> to a top level directory in icedtea-web.
>>
>> Hmhm. I'm against top level directory. Overall - it is still just for
>> testing, so it should stay in tests. Also there is eg junit-runner in
>> tests. Those two subdirectories (junit-runner and testsExtensions)
>> should be on same level.
>
> My reasoning for moving it to a top level directory is that it needs
> tests, while junit-runner doesn't :)

Can I ignore this reason as you wrote on the top of this email? O:)
/me hopes he does  not to sounds impolitely
>
>>> jnlp_testsengine isn't a test
>>> itself so I would be happy if we moved it out from under tests/. I dont
>>> think moving the tests from tests/netx/jnlp_testsengine to
>>> tests/netx/unit is a good idea; they are not netx's tests. How about
>>> creating another directory (jnlp_testengine under tests/) to contain
>>> tests for the jnlp_engine itself? (which are distinct from netx's or the
>>> plugin's tests).
>> Aboslutly agree:)
>> So what about testsExtensionsTests (or tests-extensions-tests) on same
>> level as netx (which contains unittests and  pactests (and I would like
>> to/I have  move(d) reproducers into here) and styles and junit-runne
>> rand testsExtensions?
>
> I agree that testsExtensionTests (can we have a better name, please?)
> should be in the same level as netx.
any name suggestion is welcomed!!
Although <nameOfDirectoryWeWillAgree>-tests (or Tests without -) is not nice, it is at least self explaining.
>
>> but - when to run content of testsExtensionsTests? I would like to
>> include it inside netx unit test (or let it in netx reproducers tests
>> run as it is now) rather then run special tests-run for them.
>
> I think it would make sense to run it when we build jnlp_testengine.
> This ensure that the jnlp_testengine just built works as expected.
>
Do you really want to have one more tests run? Already now I need to keep en eye on 3 test-runs results (pac, unittests,reproducers runs)
I do not mind to have them where are they now (run with reproducers) or to move them to unittests-run, but I'm against third separate run.
But your sentence you moved me more to keep them where they are - with reproducers.
If I can use my right-of-veto you granted me in headline, then they will stay where they are.
>
>>>> 3) during reproducers run launch *just* compiled testcases
>>>
>>> Could you clarify what you mean here?
>> Right now also classes which are not "test-calses" (eg everything under
>> jnlp_testengine) are launched. It is definietly wrong. Some of this will
>> be easily fixed by this refactoring, but some issues can remain.
>
> Ah. so by "just" you meant "only" (as opposed to what just means in the
> acronym JIT). Makes complete sense now :)
>
>
>> Here I have (maybe interesting) idea:
>> All our java tests are executed from junit-runner classes, which are
>> packed to junit-runner.jar
>> I would (very!) like to include also all the testsExtensions clases in
>> this jar. It will make the unifications of classpaths much more
>> straightforward (and this jar hmhm... can be useful by its cntent)
>
> Please see my note about about mixing the CPL licensed code with other
> things.
>
> Cheers,
> Omair



From andrew at icedtea.classpath.org  Thu Apr 12 10:36:31 2012
From: andrew at icedtea.classpath.org (andrew at icedtea.classpath.org)
Date: Thu, 12 Apr 2012 17:36:31 +0000
Subject: /hg/icedtea7: Fix syntax in new download rules.
Message-ID: <hg.b43c8ac7586b.1334252191.2873452341184383833@icedtea.classpath.org>

changeset b43c8ac7586b in /hg/icedtea7
details: http://icedtea.classpath.org/hg/icedtea7?cmd=changeset;node=b43c8ac7586b
author: Andrew John Hughes <ahughes at redhat.com>
date: Thu Apr 12 18:36:20 2012 +0100

	Fix syntax in new download rules.

	2012-04-12  Andrew John Hughes  <ahughes at redhat.com>

		* Makefile.am:
		(download-openjdk): Fix syntax.
		(download-cacao): Likewise.
		(download-jamvm): Likewise.


diffstat:

 ChangeLog   |   7 +++++++
 Makefile.am |  18 +++++++++---------
 2 files changed, 16 insertions(+), 9 deletions(-)

diffs (98 lines):

diff -r 887110bdf826 -r b43c8ac7586b ChangeLog
--- a/ChangeLog	Wed Apr 11 21:19:33 2012 +0100
+++ b/ChangeLog	Thu Apr 12 18:36:20 2012 +0100
@@ -1,3 +1,10 @@
+2012-04-12  Andrew John Hughes  <ahughes at redhat.com>
+
+	* Makefile.am:
+	(download-openjdk): Fix syntax.
+	(download-cacao): Likewise.
+	(download-jamvm): Likewise.
+
 2012-04-11  Andrew John Hughes  <ahughes at redhat.com>
 
 	* Makefile.am:
diff -r 887110bdf826 -r b43c8ac7586b Makefile.am
--- a/Makefile.am	Wed Apr 11 21:19:33 2012 +0100
+++ b/Makefile.am	Thu Apr 12 18:36:20 2012 +0100
@@ -855,7 +855,7 @@
 	if ! echo "$(OPENJDK_SHA256SUM)  $(OPENJDK_SRC_ZIP)" \
 	  | $(SHA256SUM) --check ; \
 	then \
-	  if test "x$${enable_downloading}" = "xyes"; then \
+	  if test "x$(enable_downloading)" = "xyes"; then \
 	    if [ -e $(OPENJDK_SRC_ZIP) ] ; then \
 	      mv $(OPENJDK_SRC_ZIP) $(OPENJDK_SRC_ZIP).old ; \
 	    fi ; \
@@ -874,7 +874,7 @@
 	if ! echo "$(CORBA_SHA256SUM)  $(CORBA_SRC_ZIP)" \
 	  | $(SHA256SUM) --check ; \
 	then \
-	  if test "x$${enable_downloading}" = "xyes"; then \
+	  if test "x$(enable_downloading)" = "xyes"; then \
 	    if [ $(CORBA_SRC_ZIP) ] ; then \
 	      mv $(CORBA_SRC_ZIP) $(CORBA_SRC_ZIP).old ; \
 	    fi ; \
@@ -893,7 +893,7 @@
 	if ! echo "$(JAXP_SHA256SUM)  $(JAXP_SRC_ZIP)" \
 	  | $(SHA256SUM) --check ; \
 	then \
-	  if test "x$${enable_downloading}" = "xyes"; then \
+	  if test "x$(enable_downloading)" = "xyes"; then \
 	    if [ $(JAXP_SRC_ZIP) ] ; then \
 	      mv $(JAXP_SRC_ZIP) $(JAXP_SRC_ZIP).old ; \
 	    fi ; \
@@ -912,7 +912,7 @@
 	if ! echo "$(JAXWS_SHA256SUM)  $(JAXWS_SRC_ZIP)" \
 	  | $(SHA256SUM) --check ; \
 	then \
-	  if test "x$${enable_downloading}" = "xyes"; then \
+	  if test "x$(enable_downloading)" = "xyes"; then \
 	    if [ $(JAXWS_SRC_ZIP) ] ; then \
 	      mv $(JAXWS_SRC_ZIP) $(JAXWS_SRC_ZIP).old ; \
 	    fi ; \
@@ -931,7 +931,7 @@
 	if ! echo "$(JDK_SHA256SUM)  $(JDK_SRC_ZIP)" \
 	  | $(SHA256SUM) --check ; \
 	then \
-	  if test "x$${enable_downloading}" = "xyes"; then \
+	  if test "x$(enable_downloading)" = "xyes"; then \
 	    if [ $(JDK_SRC_ZIP) ] ; then \
 	      mv $(JDK_SRC_ZIP) $(JDK_SRC_ZIP).old ; \
 	    fi ; \
@@ -950,7 +950,7 @@
 	if ! echo "$(LANGTOOLS_SHA256SUM)  $(LANGTOOLS_SRC_ZIP)" \
 	  | $(SHA256SUM) --check ; \
 	then \
-	  if test "x$${enable_downloading}" = "xyes"; then \
+	  if test "x$(enable_downloading)" = "xyes"; then \
 	    if [ $(LANGTOOLS_SRC_ZIP) ] ; then \
 	      mv $(LANGTOOLS_SRC_ZIP) $(LANGTOOLS_SRC_ZIP).old ; \
 	    fi ; \
@@ -969,7 +969,7 @@
 	if ! echo "$(HS_SHA256SUM)  $(HOTSPOT_SRC_ZIP)" \
 	  | $(SHA256SUM) --check ; \
 	then \
-	  if test "x$${enable_downloading}" = "xyes"; then \
+	  if test "x$(enable_downloading)" = "xyes"; then \
 	    if [ -e $(HOTSPOT_SRC_ZIP) ] ; then \
 	      mv $(HOTSPOT_SRC_ZIP) $(HOTSPOT_SRC_ZIP).old ; \
 	    fi ; \
@@ -1026,7 +1026,7 @@
 	if ! echo "$(CACAO_SHA256SUM)  $(CACAO_SRC_ZIP)" \
 	 | $(SHA256SUM) --check ; \
 	then \
-	 if test "x$${enable_downloading}" = "xyes"; then \
+	 if test "x$(enable_downloading)" = "xyes"; then \
 	   if [ -e $(CACAO_SRC_ZIP) ] ; then \
 	     mv $(CACAO_SRC_ZIP) $(CACAO_SRC_ZIP).old ; \
 	   fi ; \
@@ -1056,7 +1056,7 @@
 	if ! echo "$(JAMVM_SHA256SUM)  $(JAMVM_SRC_ZIP)" \
 	 | $(SHA256SUM) --check ; \
 	then \
-	  if test "x$${enable_downloading}" = "xyes"; then \
+	  if test "x$(enable_downloading)" = "xyes"; then \
 	    if [ -e $(JAMVM_SRC_ZIP) ] ; then \
 	      mv $(JAMVM_SRC_ZIP) $(JAMVM_SRC_ZIP).old ; \
 	    fi ; \


From ptisnovs at icedtea.classpath.org  Fri Apr 13 05:12:41 2012
From: ptisnovs at icedtea.classpath.org (ptisnovs at icedtea.classpath.org)
Date: Fri, 13 Apr 2012 12:12:41 +0000
Subject: /hg/gfx-test: 2012-04-13  Pavel Tisnovsky  <ptisnovs@redhat.com>
Message-ID: <hg.cba2ae48526e.1334319161.-6248649288953172555@icedtea.classpath.org>

changeset cba2ae48526e in /hg/gfx-test
details: http://icedtea.classpath.org/hg/gfx-test?cmd=changeset;node=cba2ae48526e
author: Pavel Tisnovsky <ptisnovs at redhat.com>
date: Fri Apr 13 14:15:12 2012 +0200

	2012-04-13  Pavel Tisnovsky  <ptisnovs at redhat.com>

		* src/org/gfxtest/framework/GfxTest.java:
		* src/org/gfxtest/framework/PrintingTest.java:
		* src/org/gfxtest/framework/TestImage.java:
		Added basic support for printing tests.
		* Makefile: Updated


diffstat:

 ChangeLog                                   |    8 +
 Makefile                                    |    1 +
 src/org/gfxtest/framework/GfxTest.java      |   54 +++++++++-
 src/org/gfxtest/framework/PrintingTest.java |  155 ++++++++++++++++++++++++++++
 src/org/gfxtest/framework/TestImage.java    |   41 +++++++
 5 files changed, 257 insertions(+), 2 deletions(-)

diffs (331 lines):

diff -r 4a4eb075c03f -r cba2ae48526e ChangeLog
--- a/ChangeLog	Thu Apr 12 14:59:12 2012 +0200
+++ b/ChangeLog	Fri Apr 13 14:15:12 2012 +0200
@@ -1,3 +1,11 @@
+2012-04-13  Pavel Tisnovsky  <ptisnovs at redhat.com>
+
+	* src/org/gfxtest/framework/GfxTest.java:
+	* src/org/gfxtest/framework/PrintingTest.java:
+	* src/org/gfxtest/framework/TestImage.java:
+	Added basic support for printing tests.
+	* Makefile: Updated
+
 2012-04-12  Pavel Tisnovsky  <ptisnovs at redhat.com>
 
 	* src/org/gfxtest/ImageDiffer/Main.java:
diff -r 4a4eb075c03f -r cba2ae48526e Makefile
--- a/Makefile	Thu Apr 12 14:59:12 2012 +0200
+++ b/Makefile	Fri Apr 13 14:15:12 2012 +0200
@@ -88,6 +88,7 @@
 	$(CLASSES)/$(FRAMEWORK_DIR)/GfxTestConfiguration.class \
 	$(CLASSES)/$(FRAMEWORK_DIR)/TestImage.class \
 	$(CLASSES)/$(FRAMEWORK_DIR)/GfxTest.class \
+	$(CLASSES)/$(FRAMEWORK_DIR)/PrintingTest.class \
 	$(CLASSES)/$(FRAMEWORK_DIR)/Log.class \
 	$(CLASSES)/$(FRAMEWORK_DIR)/ProceduralTextureFactory.class \
 	$(CLASSES)/$(FRAMEWORK_DIR)/ImageFactory.class \
diff -r 4a4eb075c03f -r cba2ae48526e src/org/gfxtest/framework/GfxTest.java
--- a/src/org/gfxtest/framework/GfxTest.java	Thu Apr 12 14:59:12 2012 +0200
+++ b/src/org/gfxtest/framework/GfxTest.java	Fri Apr 13 14:15:12 2012 +0200
@@ -1,7 +1,7 @@
 /*
   Java gfx-test framework
 
-   Copyright (C) 2010, 2011  Red Hat
+   Copyright (C) 2010, 2011, 2012  Red Hat
 
 This file is part of IcedTea.
 
@@ -43,10 +43,25 @@
 import java.awt.BasicStroke;
 import java.awt.Color;
 import java.awt.Graphics2D;
+import java.awt.print.PrinterException;
+import java.awt.print.PrinterJob;
+import java.io.File;
+import java.io.FileNotFoundException;
+import java.io.FileOutputStream;
 import java.io.IOException;
 import java.lang.reflect.InvocationTargetException;
 import java.lang.reflect.Method;
 
+
+
+import javax.print.DocFlavor;
+import javax.print.StreamPrintService;
+import javax.print.StreamPrintServiceFactory;
+import javax.print.attribute.HashPrintRequestAttributeSet;
+import javax.print.attribute.PrintRequestAttributeSet;
+import javax.print.attribute.standard.Copies;
+import javax.print.attribute.standard.MediaSizeName;
+
 import org.gfxtest.common.ConfigurationException;
 import org.gfxtest.framework.annotations.TestType;
 import org.gfxtest.framework.annotations.Zoom;
@@ -442,6 +457,8 @@
     }
 
     /**
+     * Run test configured to use bitmap as its output.
+     *
      * @param configuration
      * @param method
      * @param methodName
@@ -478,13 +495,46 @@
     }
 
     /**
+     * Run test configured to use printer as its output.
+     *
      * @param configuration
      * @param method
      * @param methodName
      */
     private void tryToRunPrintTest(GfxTestConfiguration configuration, Method method, String methodName)
     {
-        // TODO
+        String psMimeType = DocFlavor.BYTE_ARRAY.POSTSCRIPT.getMimeType(); // only this works!
+        File printOutputFile;
+        StreamPrintService streamPrintService;
+        StreamPrintServiceFactory[] factories = PrinterJob.lookupStreamPrintServices(psMimeType);
+        if (factories.length == 0)
+        {
+            System.err.println("No factories found");
+        }
+        else
+        {
+            PrinterJob printerJob = PrinterJob.getPrinterJob();
+            try
+            {
+                printOutputFile = new File(this.suiteName + "_" + methodName + ".ps");
+                streamPrintService = factories[0].getPrintService(new FileOutputStream(printOutputFile));
+                // streamPrintService can now be set as the service on a PrinterJob
+                printerJob.setPrintService(streamPrintService);
+                PrintRequestAttributeSet printAttributeSet = new HashPrintRequestAttributeSet();
+                printAttributeSet.add(MediaSizeName.ISO_A4);
+                printAttributeSet.add(new Copies(1));
+                printerJob.setPrintable(new PrintingTest(this, method));
+                printerJob.print(printAttributeSet);
+            }
+            catch (FileNotFoundException e)
+            {
+                e.printStackTrace();
+            }
+            catch (PrinterException e)
+            {
+                e.printStackTrace();
+            }
+        }
     }
 
     private void writeZoomedImage(GfxTestConfiguration configuration, TestImage sourceImage, String methodName, int zoom) throws IOException
diff -r 4a4eb075c03f -r cba2ae48526e src/org/gfxtest/framework/PrintingTest.java
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/src/org/gfxtest/framework/PrintingTest.java	Fri Apr 13 14:15:12 2012 +0200
@@ -0,0 +1,155 @@
+/*
+  Java gfx-test framework
+
+   Copyright (C) 2010, 2011, 2012  Red Hat
+
+This file is part of IcedTea.
+
+IcedTea is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+IcedTea is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with IcedTea; see the file COPYING.  If not, write to the
+Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+02110-1301 USA.
+
+Linking this library statically or dynamically with other modules is
+making a combined work based on this library.  Thus, the terms and
+conditions of the GNU General Public License cover the whole
+combination.
+
+As a special exception, the copyright holders of this library give you
+permission to link this library with independent modules to produce an
+executable, regardless of the license terms of these independent
+modules, and to copy and distribute the resulting executable under
+terms of your choice, provided that you also meet, for each linked
+independent module, the terms and conditions of the license of that
+module.  An independent module is a module which is not derived from
+or based on this library.  If you modify this library, you may extend
+this exception to your version of the library, but you are not
+obligated to do so.  If you do not wish to do so, delete this
+exception statement from your version.
+*/
+
+package org.gfxtest.framework;
+
+import java.awt.Graphics;
+import java.awt.Graphics2D;
+import java.awt.print.PageFormat;
+import java.awt.print.Printable;
+import java.awt.print.PrinterException;
+import java.lang.reflect.InvocationTargetException;
+import java.lang.reflect.Method;
+
+public class PrintingTest implements Printable
+{
+    private GfxTest gfxTest;
+    private Method method;
+    private TestResult result = null;
+
+    public PrintingTest(GfxTest gfxTest, Method method)
+    {
+        setGfxTest(gfxTest);
+        setMethod(method);
+    }
+
+    /**
+     * @return the method
+     */
+    public Method getMethod()
+    {
+        return this.method;
+    }
+
+    /**
+     * @param method the method to set
+     */
+    public void setMethod(Method method)
+    {
+        this.method = method;
+    }
+
+    /**
+     * @return the result
+     */
+    public TestResult getResult()
+    {
+        return this.result;
+    }
+
+    /**
+     * @param result the result to set
+     */
+    public void setResult(TestResult result)
+    {
+        this.result = result;
+    }
+
+    /**
+     * @return the gfxTest
+     */
+    public GfxTest getGfxTest()
+    {
+        return this.gfxTest;
+    }
+
+    /**
+     * @param gfxTest the gfxTest to set
+     */
+    public void setGfxTest(GfxTest gfxTest)
+    {
+        this.gfxTest = gfxTest;
+    }
+
+    @Override
+    public int print(Graphics graphics, PageFormat pageFormat, int pageIndex) throws PrinterException
+    {
+        if (pageIndex > 0) { /* We have only one page, and 'page' is zero-based */
+            return NO_SUCH_PAGE;
+        }
+ 
+        /* Origin (0,0) is typically outside the imageable area, so we must
+         * translate by the X and Y values in the PageFormat to avoid clipping
+         */
+        Graphics2D gc = (Graphics2D)graphics;
+        gc.translate(pageFormat.getImageableX(), pageFormat.getImageableY());
+        TestImage image = new TestImage(pageFormat.getWidth(), pageFormat.getHeight());
+        try
+        {
+            setResult((TestResult) this.method.invoke(getGfxTest(), new Object[] { image, gc }));
+        }
+        catch (IllegalArgumentException e)
+        {
+            e.printStackTrace();
+            setResult(TestResult.ERROR);
+        }
+        catch (IllegalAccessException e)
+        {
+            e.printStackTrace();
+            setResult(TestResult.ERROR);
+        }
+        catch (InvocationTargetException e)
+        {
+            e.printStackTrace();
+            setResult(TestResult.ERROR);
+        }
+
+        /*
+        graphics.setColor(Color.RED);
+        graphics.drawLine(0, 0, (int)pageFormat.getWidth(), (int)pageFormat.getHeight());
+        graphics.drawLine((int)pageFormat.getWidth(), 0, 0, (int)pageFormat.getHeight());
+
+        graphics.drawString("Hello world!", 100, 100);
+        */
+        /* tell the caller that this page is part of the printed document */
+        return PAGE_EXISTS;
+    }
+
+}
diff -r 4a4eb075c03f -r cba2ae48526e src/org/gfxtest/framework/TestImage.java
--- a/src/org/gfxtest/framework/TestImage.java	Thu Apr 12 14:59:12 2012 +0200
+++ b/src/org/gfxtest/framework/TestImage.java	Fri Apr 13 14:15:12 2012 +0200
@@ -96,6 +96,47 @@
     }
 
     /**
+     * Initialization of TestImage object.
+     * 
+     * @param width
+     *            image width
+     * @param height
+     *            image height
+     */
+    public TestImage(int width, int height)
+    {
+        this.log = new Log(this.getClass().getName(), false);
+        this.createImage(width, height);
+    }
+
+    /**
+     * Initialization of TestImage object.
+     * 
+     * @param width
+     *            image width
+     * @param height
+     *            image height
+     */
+    public TestImage(double width, double height)
+    {
+        this.log = new Log(this.getClass().getName(), false);
+        this.createImage((int)width, (int)height);
+    }
+
+    /**
+     * Create new buffered image with given width and height.
+     * 
+     * @param width
+     *            image width
+     * @param height
+     *            image height
+     */
+    public void createImage(int width, int height)
+    {
+        this.image = new BufferedImage(width, height, BufferedImage.TYPE_BYTE_BINARY);
+    }
+
+    /**
      * Create new buffered image with given width, height and image type.
      * 
      * @param configuration


From bugzilla-daemon at icedtea.classpath.org  Fri Apr 13 05:20:15 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Fri, 13 Apr 2012 12:20:15 +0000
Subject: [Bug 921] New: Nullpointer Exception when launching webstart URL:
	http://volta.canoo.com/CanooVoltaDemo
Message-ID: <bug-921-30@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=921

             Bug #: 921
           Summary: Nullpointer Exception when launching webstart URL:
                    http://volta.canoo.com/CanooVoltaDemo
    Classification: Unclassified
           Product: IcedTea-Web
           Version: 1.1.1
          Platform: x86
        OS/Version: Linux
            Status: NEW
          Severity: blocker
          Priority: P3
         Component: NetX (javaws)
        AssignedTo: omajid at redhat.com
        ReportedBy: detlef.brendle at canoo.com
                CC: unassigned at icedtea.classpath.org


When accessing the URL : http://volta.canoo.com/CanooVoltaDemo
which holds a JNLP, the IceTea plugin crashes with a NullpointerException:

I Use Firefox version 11.0 and the IcedTeaWeb Plugin version 1.1.1
The URL works fine with javaws from JDK_6.

Detlef





net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not
initialize application.
    at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:776)
    at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:552)
    at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:887)
Caused by: java.lang.NullPointerException
    at
net.sourceforge.jnlp.runtime.JNLPClassLoader.addToCodeBaseLoader(JNLPClassLoader.java:1351)
    at
net.sourceforge.jnlp.runtime.JNLPClassLoader.merge(JNLPClassLoader.java:1330)
    at
net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:305)
    at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:767)
    ... 2 more
Caused by: 
java.lang.NullPointerException
    at
net.sourceforge.jnlp.runtime.JNLPClassLoader.addToCodeBaseLoader(JNLPClassLoader.java:1351)
    at
net.sourceforge.jnlp.runtime.JNLPClassLoader.merge(JNLPClassLoader.java:1330)
    at
net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:305)
    at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:767)
    at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:552)
    at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:887)

-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


From omajid at redhat.com  Fri Apr 13 14:54:19 2012
From: omajid at redhat.com (Omair Majid)
Date: Fri, 13 Apr 2012 17:54:19 -0400
Subject: [rfc] [icedtea-web] blacklist for reproducers
In-Reply-To: <4F8712CE.1010502@redhat.com>
References: <4F7EE803.4060401@redhat.com> <4F8217B4.7050308@redhat.com>
	<4F841CB8.9000004@redhat.com> <4F8453FA.2040606@redhat.com>
	<4F86C503.80700@redhat.com> <4F870525.2000308@redhat.com>
	<4F8712CE.1010502@redhat.com>
Message-ID: <4F88A08B.40706@redhat.com>

On 04/12/2012 01:37 PM, Jiri Vanek wrote:
> On 04/12/2012 06:39 PM, Omair Majid wrote:
>> On 04/12/2012 08:05 AM, Jiri Vanek wrote:
>>> * jnlp_testengine renamed to testsExtensions, and remains in tests
>>> directory
>>
>> This is probably going into the area of bikeshedding, but I feel the
>> current name is better. Looking at existing names, I would be happy with
>> jnlp-test-engine (jnlp-test-runner, or maybe even jnlp-runner).
>>
> But this is not true. The runner is still junit-runner and nothing else.
> The content of jnlp_testengine is currently nothing more then dummy
> implementation of http server, and set of methods which make work with
> this server easy.
> And what is it else then junit extension, if it set of util methods for
> running this server executing process, wrapping those two into launching
> some jnlp/html file upon this server in javaws/browser process?
> And if some more functionalities (annotations in short term) will come,
> then it will be more and more set of..."extensions"... then just engine
> launching jnlp files.
> Another issue here is that also html files are launched now. I would
> like (at least)  to get rid of jnlp from name.
> Yes, this is bikeshedding but i do not want to make some more
> refactoring in close future.

I meant my suggestions were bikeshedding :)

If you are okay with it, let's go with test-extensions.

>>>>> 1) move all tests from tests/netx/jnlp_testsengine to tests/netx/unit
>>>>> where they belongs IMHO
>>>>
>>>> A slightly different approach might be to move jnlp_testsengine itself
>>>> to a top level directory in icedtea-web.
>>>
>>> Hmhm. I'm against top level directory. Overall - it is still just for
>>> testing, so it should stay in tests. Also there is eg junit-runner in
>>> tests. Those two subdirectories (junit-runner and testsExtensions)
>>> should be on same level.
>>
>> My reasoning for moving it to a top level directory is that it needs
>> tests, while junit-runner doesn't :)
> 
> Can I ignore this reason as you wrote on the top of this email? O:)
> /me hopes he does  not to sounds impolitely

Yes, you can ignore it :)

>> I think it would make sense to run it when we build jnlp_testengine.
>> This ensure that the jnlp_testengine just built works as expected.
>>
> Do you really want to have one more tests run? Already now I need to
> keep en eye on 3 test-runs results (pac, unittests,reproducers runs)
> I do not mind to have them where are they now (run with reproducers) or
> to move them to unittests-run, but I'm against third separate run.
> But your sentence you moved me more to keep them where they are - with
> reproducers.
> If I can use my right-of-veto you granted me in headline, then they will
> stay where they are.

I think we may be saying the same thing :)

Before you run the reproducers, you run the tests for the
jnlp_testengine, right? This is what I am saying too - we want to test
the jnlp_testengine before we actually use it.

It would be cleaner if it were a separate target and everything, but
it's not too bad as long as the jnlp_testengine is tested before we use
it to run tests.

Cheers,
Omair


From omajid at redhat.com  Fri Apr 13 15:36:48 2012
From: omajid at redhat.com (Omair Majid)
Date: Fri, 13 Apr 2012 18:36:48 -0400
Subject: Icedtea-web splashscreen implementation
In-Reply-To: <4F6CAB0A.40305@redhat.com>
References: <4F50BE87.5070508@redhat.com> <4F6B30A0.1050507@redhat.com>
	<4F6CAB0A.40305@redhat.com>
Message-ID: <4F88AA80.3000404@redhat.com>

Hi Jiri,

Err...sorry about the delay. I was under the assumption you would be
posting new(er) patches. Thanks for pinging me.

Oh, and please don't take any of this the wrong way; this is great
stuff! I just want it to be better (if possible!).

On 03/23/2012 12:55 PM, Jiri Vanek wrote:
>> Something I am a little curious about is the interaction between the
>> LaunchHandler and the splash screen. I got the feeling that NetX had
>> intended LaunchHandler to be used to indicate progress with the
>> launching of JNLP programs. And that's what I used to implement the
>> splash screens. Perhaps it might be good if we could somehow combine
>> it/split responsibilities. If the launch handler was per
>> application/applet (currently it is shared by the entire runtime), it
>> could be the one to always trigger the (right) splash screen.
>>
> 
> I do not think I understand 100% what you mean. Is it connected with
> ProgessListener ("I used to implement the splash screens") as we were
> talking on IRC when I was designing the splashscreen? (Btw I want to add
> at least interface support for this interface). Or not? (It looks like
> not) But then I do not understand.

There is a class in netx called net.sourceforge.jnlp.LaunchHandler -
that's what I am referring to. It has generically named methods
(launchInitialized, launchStarting, launchCompleted) and it seems like
it would be nice fit for handling splash screens without being
explicitly tied to splash screens. When launchStarting() is invoked, we
could call SplashScreen.show() (sorry if that's not the right method
name) from there (and similarly for the other methods). It's what netx
uses to display splash screens for jnlp applications. The only problem
is that there is only one instance per-process and we would have to
modify to make it per applet.

>> That would mean that applets and jnlps could always rely on informing
>> the launch handler (without knowing what it is) and the launch handler
>> could do the right thing (show dialog, hide splash, whatever).
> 
> If I understand this correctly I had to overlook something. I already
> did the splash-delivering method in one place, and should be easy  (I
> have factory method which is providing (splash)component for applet or
> javaws to be used) to move it to better place. But I can not see this
> common creator as you are describing it.

Yeah, but I fear it's the wrong level of abstraction. Now every place
knows about the SplashUtils class and interacts with it directly, rather
than talking to some generic interface to provide updates.

>>> Test framework was enriched for slow downloading. If the file have
>>> prefix "XslowX" then its downlaoding (even on localhost) will take
>>> 10seconds.
>>
>> I see Pavel has already pointed this out, but please no magic behaviour
>> like this. It will make life hell for the whoever ends up maintaining
>> these in the future.
> I know it is evil, But I was not able to force ALL case I needed it to
> do the same job better.

Okay, how about this: let's tackle this separately. Can you post a patch
for just this and we can try and improve it?

>> I think the "splashscreen" is doing too much. It is drawing the 
>> logo, animating it, showing error messages (and probably a lot
>> more). Can you please split this out?
> Hmhm - true. But not easy task to decomposite it  properly. Those
> tasks are very closely connected and should remain connected
> (especially form point of interface view). I think thy really should
> remains connected, but I agree that at least private decomposition
> should definitely  done. (at least also for unit testing)

No, I think the tasks (error display vs splash) is actually different.
Consider that javaws' error display is in the form of a separate dialog
and for the plugin it's inline. So we actually need multiple
implementations of just those tasks. Combining them in a super-interface
seems a little weird - especially because the error messages are not
related to the splash screen for javaws.

>> I am thinking of something like this (this is only the "view" (swing/awt
>> component) hierarchy:
>>
>> AppletViewerPanel
>>    - Main-Container
>>      - Splash Screen Container
>>      - Error Indicator Container
> 
> I disagree with this  approach. As I wrote, the tasks are very strongly
> connected. Eg splash x error screens are the same, with just different
> color schema.
> 
> I really agree, that individual components should be (privately?)
> extracted, but i would like to keep the event drivern model as it is now
> (getSpalshscreen().spin(),  getSpalshscreen().showError())  rather then
> container().replaceSpalshWithErrorSplash(factory.getDefaultError()) or
> something like this. As it seems to me you are suggesting.

Well, I guess we disagree on this point. I am against leaking
implementation details too - spin() might be better called show() (and
showing it would start the animation (which may be spinning) automatically).

> This is one of the most fundamental parts and I'm definitely looking
> forward for your feedback.
> 
> As a middle way (what is maybe the truth behind your swing/awt example)
> seems to me more and (much more) private decomposition. But to avoid of
> components parts being controlled from outside.
> eg getSpalshscreen().showError() will ionernally do : remove okDrawer
> and add errorDrawer. Which both will be some external classes doing
> their job (but I would like to avoid jcomponents for the if necessary)
> 
> What do you think?

Oh, I definitely agree on the need for private decomposition. But I also
think we need the decomposition to be visible a little more publicly.
There is no reason a splash screen should have anything to do with
errors. That fact that it does, for applets, seems more like an
implementation detail.

>> Basically, each class/object should have one task. And you can swap out
>> the splash screen with the error indicator when an error happens. If you
>> can, please split out the gui-related classes from the non-gui related
>> (the logic) classes.
>>
>>> To forward error to applet is used SplashUtils.showError set of
>>> overloaded methods.
>>
>> I just looked at the implementation of this method. Please avoid using
>> reflection. It just pushes compile time errors into runtime errors, and
>> pollutes method signatures (you know, NoSuchMethodException,
>> IllegalAccessException, IllegalArgumentException,
>> InvocationTargetException). Is
>> there an issue with using a normal interface?
>>
> 
> Definitely! Thanx for kick!
> 
>>> SplashUtils have also factory method which handles
>>> which splash (type and purpose (javaws x applet)) is about to be shown
>>> (if any - see bonuses)
>>
>> Not many places in icedtea-web make an explicit distinction between
>> javaws and applet. Instead of spreading this knowledge around, can you
>> put this in one place? JNLPRuntime seems appropriate to me, but there
>> may be a better place
> 
> Hmmm.. I made quite big effort to minimze the splitting(/or even
> doubling!) of functionality. And except two the calls of factory (one
> form applet, one from javaws) there in none. Can you be little bit more
> specific in your request (or better to point the place where the splash
> could be set uniformly (I do not believe there is such a place!))
> 

Well, that's sort of my point. This isn't specific to the splash screen
at all. If the splash screen needs this, other parts probably do too.
Can we move this to, say, the JNLPRuntime class? IIRC, it already has a
constructor/flag to differentiate applets from jnlp.

>>> There are actually three and half types of splashscreen. Applet one
>>> (which have error variation also), javaws one (forced by specification,
>>> which also forces title,vendor and homepage with description to be
>>> shown),
>>
>> This is not quite true. I know what the "specification" says, but other
>> implementations do not follow this particular requirement.
> 
> I have no problems to ignore this requirement, but I consider it quite
> reasonable (it shows to user what he is trying to download, and if it
> somehow similar what he is expecting to download)

Oh, some sort of indication is nice, but again, are you sure the splash
screen is the right place for this? For jnlp, we do show the urls in the
download indicators.

>>> and java's -spalsh which is showing image until control is
>>> forwarded to netx.
>>
>> Let's not worry about this one ;)
> 
> But I really like it! It cost us nothing, and when eg initial jnlp is
> downloaded very slowly it save a lot! Also for different tasks it is
> nice to see that IcedTea-web is running! (That "something is happening"
> by different way then to watch the LEDs on computer;) )

Hm..the idea is nice, but I am not a huge fan of it yet. Can we discuss
this separately? I think there are a few things that we can do here to
make it even better.

>>> The factory method have parameter whether to provide splash for javaws
>>> (it is showing also information from information element (vendor,
>>> description,homepage,title..) - specification commanding)
>>
>> Out of curiosity, why did you decide to implement InformationElement? Is
>> InformationDesc not sufficient?
> 
> As a keeper of information is absolutely enough. Think about it as of
> some kind of wrapper which is doing for spalsh specific operations which
> deserved to be implemented elsewhere - in this case i18n and searching
> for best matches. (And handling nulls :) )

I am not fully convinced yet, but I don't particularly see how this
could be bad (other than duplication more-or-less trivial stuff). So, okay.

>>> The showing of error screen is very successfull, but one case I was
>>> unable to catch - when connection with server dies in middle of resource
>>> transfer and TODO - I have forgot to test signatures and stuff around:-/
>>> - but this should be handled n netx-way too.
>>
>> Unit tests to check this, please!
> 
> Especially for signed jars very hard to do. But I will definitely kept
> in mind unit coverage. And will at least try the behaviour.

I said unit tests, not reproducers! ;)

Whether the jars are signed or not shouldn't affect unit tests at all.

>>> I'm showing also version on splash (and forwarding it to error mesage)
>>> (ok?) - Looks to me like good idea....
>>
>> Not sure if showing version on the splash itself is a great idea,
> Lets vote O:) Now it is 1:1 ;)
>> but I
>> agree it is good to show it in the error.
> It is.
>>

TBH, this doesn't seem like a big deal. If you want it, sure. But please
do consider if it will be helpful for the average user. There is no
point presenting them with extra information if that information is
meaningless to them.

>>> _bonuses_
>>> I have added recognition of two environment variables -
>>> ICEDTEA_WEB_PLUGIN_SPLASH and ICEDTEA_WEB_SPLASH. Those variables alow
>>> user to change splahs screen before lunchtime and - what is real reason
>>> for those two variables - to disable splashscreen at all.
>>
>> The only environment variable that IcedTea-Web currently uses is
>> ICEDTEAPLUGIN_DEBUG. It would be great if all the names were (somehow)
>> consistent.
> 
> yap!
> 
> what do you thing of:
> ICEDTEAPLUGIN_DEBUG
> ICEDTEAPLUGIN_SPLASH
> ICEDTEAWEB_SPLASH

So the first two are for the plugin, and the last one for netx? I feel
netx is not being given the same status as the plugin ;)

Cheers,
Omair


From bugzilla-daemon at icedtea.classpath.org  Sat Apr 14 05:45:33 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Sat, 14 Apr 2012 12:45:33 +0000
Subject: [Bug 797] Compiler error message does not display entire file name
	and path
In-Reply-To: <bug-797-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-797-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-797-30-S0wIE1UmZx@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=797

Matthias Klose <doko at ubuntu.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |doko at ubuntu.com

--- Comment #1 from Matthias Klose <doko at ubuntu.com> 2012-04-14 12:45:33 UTC ---
while the patch is in, I still see this with the 1.11 branch.

http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-March/013178.html

the bug number should be mentioned in the ChangeLog

-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


From jgh at FreeBSD.org  Sat Apr 14 12:20:14 2012
From: jgh at FreeBSD.org (Jason Helfman)
Date: Sat, 14 Apr 2012 12:20:14 -0700
Subject: porting icedtea6 to FreeBSD
In-Reply-To: <20120330000418.GC11448@dormouse.experts-exchange.com>
References: <20120329162840.GE6444@dormouse.experts-exchange.com>
	<3f7e7672-2c17-468b-b8f1-707544b49b27@zmail17.collab.prod.int.phx2.redhat.com>
	<20120330000418.GC11448@dormouse.experts-exchange.com>
Message-ID: <CAMuy=+hj4r2L3N137q+5B4qdDvJQDbvrtAUDU2yWS7xK12kYHg@mail.gmail.com>

On Thu, Mar 29, 2012 at 5:04 PM, Jason Helfman <jgh at freebsd.org> wrote:

> On Thu, Mar 29, 2012 at 06:49:25PM -0400, Andrew Hughes thus spake:
>
>  I don't know what's available on FreeBSD.  We've tended to use gcj to get
>> off the starting blocks, but OpenJDK6 works too.
>>
>
> I'll try openjdk6 first, and then if I can get it to work try others.
>
>  What makes you say I am not using the latest? I did update to 1.11.1
>>> for
>>> this latest build.
>>> https://redports.org/browser/**jgh/java/icedtea6/Makefile<https://redports.org/browser/jgh/java/icedtea6/Makefile>
>>>
>>
>> Ok I didn't see that.  Sorry.
>> As I say, you may still find hg useful for contributing back.
>>
>
> Ok, I'll keep this in mind.
>
>
>>> Yes, I noticed this with the change to 1.11.1, and removed those from
>>> my
>>> Makefile.
>>>
>>
>> Good.
>>
>>  >>
>>> >> This has been resolved with later releases, and the patching is
>>> >> probably a
>>> >> result of misconfigured configured options.
>>> >
>>> >I doubt it from what I've seen of what you're doing.
>>> >
>>> >The issue seems to be that your OpenJDK sources are not in the
>>> >expected state.
>>>
>>> It is the same checksum, though, and the same location that is
>>> fetched
>>> during the icedtea build. I just pre-fetch them, and assign it as a
>>> configure option.
>>> Here is a link to the files with the checksums that are used:
>>> https://redports.org/browser/**jgh/java/icedtea6/distinfo<https://redports.org/browser/jgh/java/icedtea6/distinfo>
>>>
>>>
>> Can you provide a log of what happens when you run make?  Something
>> is clearly going wrong, but I can't see what if the tarballs are ok.
>> Are you starting from a clean directory?
>>
>
> I am starting from a clean directory every time I build.
> Attached is the log you've requested.
>
> Thanks!
>
> Any thoughts on any of this?
Thanks, again.

-jgh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120414/8c897ede/attachment.html 

From bugzilla-daemon at icedtea.classpath.org  Sat Apr 14 13:26:54 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Sat, 14 Apr 2012 20:26:54 +0000
Subject: [Bug 922] New: A fatal error has been detected by the Java Runtime
	Environment
Message-ID: <bug-922-30@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=922

             Bug #: 922
           Summary: A fatal error has been detected by the Java Runtime
                    Environment
    Classification: Unclassified
           Product: MIPS Port
           Version: unspecified
          Platform: x86
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: general
        AssignedTo: unassigned at icedtea.classpath.org
        ReportedBy: leosqual at yahoo.fr


Created attachment 680
  --> http://icedtea.classpath.org/bugzilla/attachment.cgi?id=680
An error report file

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x038a976c, pid=20982, tid=3077641920
#
# JRE version: 6.0_24-b24
# Java VM: OpenJDK Client VM (20.0-b12 mixed mode linux-x86 )
# Derivative: IcedTea6 1.11.1
# Distribution: Fedora release 16 (Verne), package fedora-65.1.11.1.fc16-i386
# Problematic frame:
# C  [libxul.so+0xd5076c]  NS_InvokeByIndex_P+0x5d90
#
# An error report file with more information is saved as:
# /opt/BOS-5.6.2/studio/hs_err_pid20982.log
#
# If you would like to submit a bug report, please include
# instructions how to reproduce the bug and visit:
#   http://icedtea.classpath.org/bugzilla
#

-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


From bugzilla-daemon at icedtea.classpath.org  Sat Apr 14 15:36:21 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Sat, 14 Apr 2012 22:36:21 +0000
Subject: [Bug 918] java applet windows uses a low resulution black/white icon
In-Reply-To: <bug-918-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-918-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-918-30-ZtGYzktijz@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=918

--- Comment #1 from Omair Majid <omajid at redhat.com> 2012-04-14 22:36:21 UTC ---
Thanks for reporting the bug.

Yes, having netx icons and names may be confusing for the user.

(In reply to comment #0)
> delete the file netx-icon.png from '''/usr/share/icedtea-web/netx.jar''' > net
> > sourceforge > jnlp >resources. then it will use the icon wich is given in the
> /usr/share/applications/icedtea-netx-javaws.desktop file

The plugin is not associated with that desktop file. Making this change will
cause icedtea-web to fall back to the default icon used by the jre for java
applications (which on some distributions, should be
/usr/share/icons/default/[somesize]/java.png). Arguably, that's even better.

-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


From bugzilla-daemon at icedtea.classpath.org  Sat Apr 14 16:49:47 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Sat, 14 Apr 2012 23:49:47 +0000
Subject: [Bug 918] java applet windows uses a low resulution black/white icon
In-Reply-To: <bug-918-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-918-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-918-30-I2xpzA9ENG@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=918

--- Comment #2 from Omair Majid <omajid at redhat.com> 2012-04-14 23:49:47 UTC ---
Actually, /usr/share/icons/default/[somesize]/java.png isn't right. The default
icon image is either swing's (JavaCup{16,32}.png in openjdk's resources.jar) or
awt's (XAWTIcon*_java_icon*png.class in openjdk's rt.jar)

-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


From fcassia at gmail.com  Sun Apr 15 10:05:05 2012
From: fcassia at gmail.com (Fernando Cassia)
Date: Sun, 15 Apr 2012 14:05:05 -0300
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream, its
	name should be openjdk-plugin !
Message-ID: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>

I was having the argument on the Fedora mailing list so I decided to
bring this here.

In the Windows world, you install Java, and get the whole enchilada...
Java JRE, browser plug-in, and Java Web Start JWS support.
Plus, the plug-in is configured to immediately start working
system-wide on all installed browsers.

So the end user just "installs java" and is done with it.

In the Linux world... it's different, mostly for historical reasons
that MAKE NO SENSE for the end user, who might not even be aware that
"Open source Java" (OpenJDK) includes the JRE but not the browser
plug-in. And even if he is aware of such fact, he wants to install
OpenJDK "and the browser plug-in for it". He doesn't care whether the
name is "OpenJDK plug-in" "Icedtea-web" "Classpath on a large glass,
on the rocks" or "TITOPNOTPOOP" (This Is The OpenJDK Plugin, NOT Part
of OPenjdk).

He doesn' t care. He shouldn' t care.

So, while my dream would be for Icedtea-web to be merged with OpenJDK
and become "openjdk-plugin" I imagine this would rub the Icedtea team
the wrong way, for all the usual egotistical reasons. So, at this
point, I don't want to start an ugly argument, let's say that for the
time being it'd suffice if IcedTea-Web team recommends distros to
include an alias for the Icedtea-web package, named "openjdk-plugin"
becase, gee, not everyone in the world knows that the open source java
has a plugin with a totally unrelated name to the open source java
package name (OpenJDK).

So when someone wants to "install Java" (and by "install Java" I mean
' the full Java experience, JRE,plugin, and JWS '), he would just "yum
install openjdk*" and get all necessary packages, openjdk and also
icedtea-web (because the package manager will pickup openjdk-plugin as
Icedtea-web).

This shows the need for a linux "UX" (User Experience) manager.
Programmers don't think about these small issues that just confuse
newcomers to the platform.

Thoughts? Comments? Expletives? ;-)
FC
-- 
During times of Universal Deceit, telling the truth becomes a revolutionary act
- George Orwell


From aph at redhat.com  Sun Apr 15 10:40:48 2012
From: aph at redhat.com (Andrew Haley)
Date: Sun, 15 Apr 2012 18:40:48 +0100
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its name should be openjdk-plugin !
In-Reply-To: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>
Message-ID: <4F8B0820.7050001@redhat.com>

On 04/15/2012 06:05 PM, Fernando Cassia wrote:
> In the Linux world... it's different, mostly for historical reasons
> that MAKE NO SENSE for the end user, who might not even be aware that
> "Open source Java" (OpenJDK) includes the JRE but not the browser
> plug-in.

Actually, it's the other way around: the plugin used to be part of the
Fedora openjdk packages until recently.  We spun it out because we
need to be able to update it asynchronously.  So, the reason it's
separate is purely technical, and necessary.

> it'd suffice if IcedTea-Web team recommends distros to include an
> alias for the Icedtea-web package, named "openjdk-plugin" becase,
> gee, not everyone in the world knows that the open source java has a
> plugin with a totally unrelated name to the open source java package
> name (OpenJDK).

That's not totally unreasonable.  Is the issue simply that the name of
the plugin doesn't come up when you're searching for a package name
with yum?

Andrew.



From fcassia at gmail.com  Sun Apr 15 10:54:22 2012
From: fcassia at gmail.com (Fernando Cassia)
Date: Sun, 15 Apr 2012 14:54:22 -0300
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream, its
	name should be openjdk-plugin !
In-Reply-To: <4F8B0820.7050001@redhat.com>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>
	<4F8B0820.7050001@redhat.com>
Message-ID: <CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>

On Sun, Apr 15, 2012 at 14:40, Andrew Haley <aph at redhat.com> wrote:
> Actually, it's the other way around: the plugin used to be part of the
> Fedora openjdk packages until recently. ?We spun it out because we
> need to be able to update it asynchronously. ?So, the reason it's
> separate is purely technical, and necessary.

Hi Andrew

Technically, call it Supacatchatroopa* if you guys so wish.
I wasn't speaking about technical organization of the programming
team, internal code name, etc.
Or whether one

I was speaking about a concept that might sound foreign to
programmers: USER EXPERIENCE.

Here I go again:

1. There' s one "Open Source Java" package. Its name is OpenJDK
2. Unlike in the Windows, Mac and Linux JRE world, the plug-in and JWS
in this version of "Open Source Java" is not part of the main package,
it' s an external one.
3. The user who install Java, usually wants the full Java experience.
In other words, he installs OpenJDK to run Java desktop apps, applets,
and run Java Web Start apps.
4. If he uses his favorite package manager and types OpenJDK, and
chooses to install that, he gets a "half-Java" (OpenJDK but no plug-in
and no JWS support).
5. So he scratches his head while thinking "I've got Java, but no
plug-in. But I just installed OpenJDK!".
6. He has to somehow ask for help on mailing lists, once someone tells
him "that' s because the Java plug-in and JWS support for OpenJDK is
called Icedtea, you d*rk, how didn't you figure that out yourself?"
(I'm exaggerating for dramatic effect).

So, again, why can't the package now known as Icedtea-web be called
"OpenJDK-plugin"?
I think "because some eons ago there was some package dubbed
openjdk-plugin and renaming Icedtea-web would put at risk the balance
of the Universe" is not a valid excuse, IMHO.

>> it'd suffice if IcedTea-Web team recommends distros to include an
>> alias for the Icedtea-web package, named "openjdk-plugin" becase,
>> gee, not everyone in the world knows that the open source java has a
>> plugin with a totally unrelated name to the open source java package
>> name (OpenJDK).
>
> That's not totally unreasonable. ?Is the issue simply that the name of
> the plugin doesn't come up when you're searching for a package name
> with yum?

The issue is simply the name, totally unrelated to OpenJDK. If
Icedtea-web is the de-facto plug-in implementation for OpenJDK,
why-oh-why not call it "OpenJDK Plug-in"?. You can keep the icedtea
name for other parts of code that do not affect the end user
experience (hooks to alternative VMs, etc).

as per
http://openjdk.java.net/projects/icedtea/
"In due time, we hope that many of the enhancements provided by
IcedTea will appear in the main OpenJDK7 development tree"

Is my request too unreasonable?. Again, it's not about the technical
organization of the project, it's not about code, it's not about
repos, it's about the END USER'S EXPERIENCE of "Installing OpenJDK for
Java support, and the plug-in that goes along with it". How would you
name such plugin? packagename-plugin or supacatchatroopa*?

Thanks for your time.

FC
* Supacatchatroopa
http://www.uvlist.net/game-34328-Supacatchatroopa

-- 
During times of Universal Deceit, telling the truth becomes a revolutionary act
- George Orwell


From aph at redhat.com  Sun Apr 15 10:57:22 2012
From: aph at redhat.com (Andrew Haley)
Date: Sun, 15 Apr 2012 18:57:22 +0100
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its name should be openjdk-plugin !
In-Reply-To: <CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>
	<4F8B0820.7050001@redhat.com>
	<CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>
Message-ID: <4F8B0C02.6070406@redhat.com>

On 04/15/2012 06:54 PM, Fernando Cassia wrote:
> On Sun, Apr 15, 2012 at 14:40, Andrew Haley <aph at redhat.com> wrote:
>> Actually, it's the other way around: the plugin used to be part of the
>> Fedora openjdk packages until recently.  We spun it out because we
>> need to be able to update it asynchronously.  So, the reason it's
>> separate is purely technical, and necessary.
> 
> Hi Andrew
> 
> Technically, call it Supacatchatroopa* if you guys so wish.
> I wasn't speaking about technical organization of the programming
> team, internal code name, etc.
> Or whether one
> 
> I was speaking about a concept that might sound foreign to
> programmers: USER EXPERIENCE.

If you're going to be rude and sarcastic, I'm going to ignore you.
I could help you.  Your call.

Andrew.


From fcassia at gmail.com  Sun Apr 15 11:02:59 2012
From: fcassia at gmail.com (Fernando Cassia)
Date: Sun, 15 Apr 2012 15:02:59 -0300
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream, its
	name should be openjdk-plugin !
In-Reply-To: <4F8B0C02.6070406@redhat.com>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>
	<4F8B0820.7050001@redhat.com>
	<CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>
	<4F8B0C02.6070406@redhat.com>
Message-ID: <CACGw4H5J7Y1aWc5EFfqPaugy5UNrSzg-qS_N7Aoafu9nYA45Pw@mail.gmail.com>

On Sun, Apr 15, 2012 at 14:57, Andrew Haley <aph at redhat.com> wrote:
> If you're going to be rude and sarcastic, I'm going to ignore you.
> I could help you. ?Your call.
>
> Andrew.

Don't take it personal Andrew. I was just trying to make my point in
the strongest way possible.

I can be civil, too. It just blows my mind when I see tiny little
annoyances in FOSS products which arent solved -or even identified as
problems- because very few people think as an end user.

FC


From fcassia at gmail.com  Sun Apr 15 11:37:46 2012
From: fcassia at gmail.com (Fernando Cassia)
Date: Sun, 15 Apr 2012 15:37:46 -0300
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream, its
	name should be openjdk-plugin !
In-Reply-To: <4F8B0C02.6070406@redhat.com>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>
	<4F8B0820.7050001@redhat.com>
	<CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>
	<4F8B0C02.6070406@redhat.com>
Message-ID: <CACGw4H5ZcT_zjD=v-hsDrzxaBqrG9XV774dhwKQYKh7ULL_=dA@mail.gmail.com>

On Sun, Apr 15, 2012 at 14:57, Andrew Haley <aph at redhat.com> wrote:
> If you're going to be rude and sarcastic, I'm going to ignore you.

Sorry Andrew, I apologize. Sarcastic is my usual mode* when I have to
explain a broad concept that I "feel" should be obvious to the other
party -but most of the time, isn't-.

Did'n mean to be rude.

FC
* http://www.personalitypage.com/INTJ.html

-- 
During times of Universal Deceit, telling the truth becomes a revolutionary act
- George Orwell


From fw at deneb.enyo.de  Sun Apr 15 11:44:45 2012
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sun, 15 Apr 2012 20:44:45 +0200
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its name should be openjdk-plugin !
In-Reply-To: <CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>
	(Fernando Cassia's message of "Sun, 15 Apr 2012 14:54:22 -0300")
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>
	<4F8B0820.7050001@redhat.com>
	<CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>
Message-ID: <87lilwsule.fsf@mid.deneb.enyo.de>

* Fernando Cassia:

> So, again, why can't the package now known as Icedtea-web be called
> "OpenJDK-plugin"?

Because it's a component which hasn't got to do much with OpenJDK.
The plugin derives from a separate code base.  Furthermore, Oracle has
asked the public not to use "OpenJDK" for programs which are not
substantially the same as something which Oracle publishes under the
name "OpenJDK".

That being said, I'm not even sure if it is a good idea to make the
plug-in easier to install.  It's the main way the OpenJDK code base is
exposed to mobile code, after all.


From fcassia at gmail.com  Sun Apr 15 12:03:44 2012
From: fcassia at gmail.com (Fernando Cassia)
Date: Sun, 15 Apr 2012 16:03:44 -0300
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream, its
	name should be openjdk-plugin !
In-Reply-To: <87lilwsule.fsf@mid.deneb.enyo.de>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>
	<4F8B0820.7050001@redhat.com>
	<CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>
	<87lilwsule.fsf@mid.deneb.enyo.de>
Message-ID: <CACGw4H4c+dYKtNFaP+UKJg3ZEtMp0RZGavGRMjvbms9PGJoErg@mail.gmail.com>

On Sun, Apr 15, 2012 at 15:44, Florian Weimer <fw at deneb.enyo.de> wrote:
> Because it's a component which hasn't got to do much with OpenJDK.

In my view it has much to do with OpenJDK. It provides the only
working plug-in implementation to be used with OpenJDK.

> The plugin derives from a separate code base.

Again, for the end user, this is meaningless. The code could derive
from the International Space Station. (joke, joke!)

>?Furthermore, Oracle has
> asked the public not to use "OpenJDK" for programs which are not
> substantially the same as something which Oracle publishes under the
> name "OpenJDK".

http://icedtea.classpath.org/wiki/Main_Page
"The IcedTea project provides (...) and adds a number of key features
to the upstream OpenJDK codebase:
    A Free 64-bit plugin with LiveConnect and Java Web Start support"

> That being said, I'm not even sure if it is a good idea to make the
> plug-in easier to install.

Why not drop it altogether, then? Along with Java Web Start, just
because there's the remote possibility of someone using it badly.

Instead of fixing code, just remove it and be done with it.
Now this is sarcasm.

> ?It's the main way the OpenJDK code base is
> exposed to mobile code, after all.

I guess you mean hostile code?. Well, the web is hostile. But I don't
see Mozilla making an argument about making Firefox harder to install
because some sites might cause problems or contain malware.

I'm saddened now, all I wanted to do was making a case about improving
the end user experience for Java (OpenJDK) users on Linux. And what I
got so far (saving Andrew's first response hinting it wasn't such a
bad idea), is reaction against change. The status quo must be
wonderful, then.

I just wanted to promote the great Java apps available via JWS out
there, apps that I use frequently like

http://antaki.ca/bloom/Bloom.jnlp
http://ho.io/jdiskreport
http://ho.io/mu-commander
http://jshot.info/jshot/webstart/jshot.jnlp
http://download.powerfolder.com/pro/webstart/PowerFolder.jnlp
http://omegat.sourceforge.net/webstart.html

...just to name a few.

But I can't/Won't do it if installing OpenJDK on Linux leaves users
with an incomplete user experience, because the plug-in has a strange
name that no one knows about.

Sincerelly

FC
-- 
During times of Universal Deceit, telling the truth becomes a revolutionary act
- George Orwell


From fcassia at gmail.com  Sun Apr 15 12:27:53 2012
From: fcassia at gmail.com (Fernando Cassia)
Date: Sun, 15 Apr 2012 16:27:53 -0300
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream, its
	name should be openjdk-plugin !
In-Reply-To: <87aa2cstbv.fsf@mid.deneb.enyo.de>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>
	<4F8B0820.7050001@redhat.com>
	<CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>
	<87lilwsule.fsf@mid.deneb.enyo.de>
	<CACGw4H4c+dYKtNFaP+UKJg3ZEtMp0RZGavGRMjvbms9PGJoErg@mail.gmail.com>
	<87aa2cstbv.fsf@mid.deneb.enyo.de>
Message-ID: <CACGw4H5yWav9s92ttbEdJ2CGDf1TO_FW+MV2sefHOHgUvMr72A@mail.gmail.com>

On Sun, Apr 15, 2012 at 16:12, Florian Weimer <fw at deneb.enyo.de> wrote:
> There's a plan to make running browser plugins slightly more
> difficult: <https://wiki.mozilla.org/Opt-in_activation_for_plugins>
>
> Similarly, Microsoft has added a warning to prevent unattended
> launching of XBAPs.

Yes, but AFAIK it doesn't extend to making the technologies harder to
install or to find.

To enforce that would be a job/problem of the browser.

Again, my point is making people who install OpenJDK easier to
find/install the plug-in that goes along with it.

yum install openjdk7
currently installs openjdk, but not the plug-in that goes along with
it (Icedtea)
whereas if there was a package name-alias (I'm not sure if alias if
the current term, I suspect so) for Icedtea that matches
openjdk-plugin, then
a user typing

yum install openjdk7*

...would automagically pick up OpenJDK, and the plug-in that goes
along with it, bacause yum would pick up openjdk7, and openjdk7-plugin
(IcedTea).

Of course, in this conservative approach, those who type only "yum
install openjdk" would get just the OpenJDK and not IcedTea, just as
happens right now. But the openjdk-plugin alias name to Icedtea would
greatly increase its visibility, *IMHO*

And after all, more users using the IcedTea code -and thus more bug
finders- wouldn't be something Icedtea devs would be asking for?. I
found it a bit odd to find devs ashamed of their own code, calling for
ways to make the code harder to find or to install, citing the recent
security scare.

FC

-- 
During times of Universal Deceit, telling the truth becomes a revolutionary act
- George Orwell


From thomas at m3y3r.de  Sun Apr 15 13:03:06 2012
From: thomas at m3y3r.de (Thomas Meyer)
Date: Sun, 15 Apr 2012 22:03:06 +0200
Subject: RFC - Reduce loading of PropertiesFile
In-Reply-To: <4F86D475.5020202@redhat.com>
References: <1334087640.1431.26.camel@localhost.localdomain>
	<4F86D475.5020202@redhat.com>
Message-ID: <1334520186.1444.43.camel@localhost.localdomain>

Am Donnerstag, den 12.04.2012, 15:11 +0200 schrieb Jiri Vanek:
> Hi!

Hey!

> diffs as attachments and changelogs as plaintext please :)

oops! Yes, sorry. Here you go:

2012-04-15  Thomas Meyer <thomas at m3y3r.de>

	* netx/net/sourceforge/jnlp/util/PropertiesFile.java
	Reduce no. of disk accesses in (load) when the recently_used file was not
	changed since the last (store).
	* netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java: (load)
	Avoid call of (checkData), when file was not changed.

New patch(es) against tip as attachment.

> 
> Idea looks excelent, but several issues inline:
> 
> On 04/10/2012 09:54 PM, Thomas Meyer wrote:
> > diff -r 60ef5191add3 netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java
> > --- a/netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java	Tue Apr 10 19:10:43 2012 +0200
> > +++ b/netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java	Tue Apr 10 21:49:08 2012 +0200
> > @@ -108,11 +108,11 @@
> >        * Update map for keeping track of recently used items.
> >        */
> >       public synchronized void load() {
> > -        cacheOrder.load();
> > +        boolean loaded = cacheOrder.load();
> >           /*
> >            * clean up possibly corrupted entries
> >            */
> > -        if (checkData()) {
> > +        if (loaded == true&&  checkData()) {
> +        if (loaded && checkData()) {
> please ;)
> (unless it somehow destroy difference between && and & O:) )

&& is the right thing to do here! we want to avoid the call of
checkData(), when the file was not reloaded.

> 
> >               if (JNLPRuntime.isDebug()) {
> >                   new LruCacheException().printStackTrace();
> >               }
> > @@ -125,7 +125,7 @@
> >       /**
> >        * check content of cacheOrder and remove invalid/corrupt entries
> >        *
> > -     * @return true, if cache was coruupted and affected entry removed
> > +     * @return true, if cache was corrupted and affected entry removed
> >        */
> >       private boolean checkData () {
> >           boolean modified = false;
> > diff -r 60ef5191add3 netx/net/sourceforge/jnlp/util/PropertiesFile.java
> > --- a/netx/net/sourceforge/jnlp/util/PropertiesFile.java	Tue Apr 10 19:10:43 2012 +0200
> > +++ b/netx/net/sourceforge/jnlp/util/PropertiesFile.java	Tue Apr 10 21:49:08 2012 +0200
> > @@ -35,6 +35,9 @@
> >
> >       /** the header string */
> >       String header = "netx file";
> > +
> > +    /** time of last modification */
> > +    long lastStore;
> >
> >       /** lazy loaded on getProperty */
> >       boolean loaded = false;
> > @@ -104,24 +107,32 @@
> >        * Ensures that the file backing these properties has been
> >        * loaded; call this method before calling any method defined by
> >        * a superclass.
> > +     *
> > +     * @return true, if file was (re-)loaded
> > +     *         false, if file was still current
> >        */
> > -    public void load() {
> > +    public boolean load() {
> >           loaded = true;
> Looks like unused?

No. This is an already present optimisation to lazy load the file on the
first call of getProperty().

> >
> > -        InputStream s = null;
> > -        try {
> this
> > -            if (!file.exists())
> > -                return;
> should remains here, returning false, as you are testing file.lastModified() later
okay.

> 
> > +        if(lastStore == 0 || lastStore>  0&&  file.lastModified() != lastStore) {
> I believe this lastStore>  0 is redudat:
> if(lastStore == 0 || file.lastModified() != lastStore)
> will do the same thing?

lastModified() tells:
"returns [...] 0L if the file does not exist or if an I/O error occurs"

lastStore will be zero as it is initialised at object creation time.

so I wanted to make sure to at least try to load the file once.
does that makes sense?

> 
> > +            InputStream s = null;
> > +            try {
> this
> > +                if (!file.exists())
> > +                    return false;
> will be redundant then (^^^)

okay.

> > +
> > +                try {
> > +                    s = new FileInputStream(file);
> When you are touching this, I believe the encoding of this file should be during storing and loading 
> namely specified as utf-8 (icedtea-web have issues with encodings... so its better to start sooner 
> then later)

FileInputStream is a byte stream, so no character set is interpreted
here. also the class PropertiesFile is an subclass of Properties.

Properties.load() tells:

"Reads a property list (key and element pairs) from the input byte
stream. The input stream is in a simple line-oriented format as
specified in load(Reader) and is assumed to use the ISO 8859-1 character
encoding; that is each byte is one Latin1 character. Characters not in
Latin1, and certain special characters, are represented in keys and
elements using Unicode escapes."

so I think we should not use a different character set here.

> > +                    load(s);
>        *1 (see below ;)
> > +                } finally {
> > +                    if (s != null) s.close();
> > +                }
> > +            } catch (IOException ex) {
> > +                ex.printStackTrace();
> return false here?

yes, of course. fixed.

> > +            }
> > +            return true;
> no return here here
> > +        }
> >
> > -            try {
> > -                s = new FileInputStream(file);
> > -                load(s);
> > -            } finally {
> > -                if (s != null) s.close();
> > -            }
> > -        } catch (IOException ex) {
> > -            ex.printStackTrace();
> > -        }
> > +        return false;
> shouldn't  there be return true/nothing (returns already solved) - considering my hints are valid?
> >       }
> >
> >       /**
> > @@ -137,6 +148,7 @@
> >                   file.getParentFile().mkdirs();
> >                   s = new FileOutputStream(file);
> >                   store(s, header);
> > +                lastStore = file.lastModified();
> This is shouldn't be there. I would like to move lastStore = file.lastModified(); to load function. 

fixed.

> or  to "*1" location (because reason of this timestamp is also external modification of recently_used)
> >               } finally {
> >                   if (s != null) s.close();
> >               }
> >
> >
> Little bit of-the-basin think - are you sure that store() as it is written changes lastModified() 
> linux stamp correctly? (I had some bad experiences with this, but have never examined it separately)

no. a fsync() was missing here. fixed.

> 
> Also I would like to suggest at least two tests with this patch
> 1) generate eg 1mb recently_used file and measure set some deadline how fast javaws  have to start. 
>    The value should be failing without this patch, and  passing with this one applied. Also some 
> real number how faster this is will be much appreciate!
> 
> 2) second one will be little bit more difficult. It would be nice to test, that when recently_used 
> is modified during javaws run, then it reloads it correctly. And so verify that this patch will not 
> cause some regression.
> 
> 
> Maybe unittest will be easier to prepare instead of 2)
> But I'm afraid those (or similar ) tests will be really necessary.

I'll write some test cases and will get some figures.

> What do you think?

sounds good to me.

> 
> btw - there is task[1] which have long-term goal to rewrite cache subsystem. Do you want to be 
> volunteer?

Sorry, but I can only do some small contributions, as this is just a
hobby for me. This sounds more like a full-time job...

with kind regards
thomas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: reduce-load.patch
Type: text/x-patch
Size: 6642 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120415/0e72f3a3/reduce-load.patch 

From mark at klomp.org  Mon Apr 16 00:31:59 2012
From: mark at klomp.org (Mark Wielaard)
Date: Mon, 16 Apr 2012 09:31:59 +0200
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its name should be openjdk-plugin !
In-Reply-To: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>
Message-ID: <20120416073159.GB21928@toonder.wildebeest.org>

On Sun, Apr 15, 2012 at 02:05:05PM -0300, Fernando Cassia wrote:
> I was having the argument on the Fedora mailing list so I decided to
> bring this here.

It is a packaging issue, so it seems better to discuss this on the
Fedora list directly.

> So, while my dream would be for Icedtea-web to be merged with OpenJDK
> and become "openjdk-plugin" I imagine this would rub the Icedtea team
> the wrong way, for all the usual egotistical reasons. So, at this
> point, I don't want to start an ugly argument, let's say that for the
> time being it'd suffice if IcedTea-Web team recommends distros to
> include an alias for the Icedtea-web package, named "openjdk-plugin"
> becase, gee, not everyone in the world knows that the open source java
> has a plugin with a totally unrelated name to the open source java
> package name (OpenJDK).

Even if it is a good idea to have consistent naming, your case isn't
being helped by insulting the hackers you are asking help from. But you
are really asking the wrong people. Oracle has decided to take a trademark
on OpenJDK, they allow distros to call IcedTea (in certain configurations)
OpenJDK, but they don't allow this for IcedTea-Web. Please go ask them
if you want them to clean up their trademark license to allow this.

Thanks,

Mark


From aph at redhat.com  Mon Apr 16 01:23:29 2012
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 Apr 2012 09:23:29 +0100
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its name should be openjdk-plugin !
In-Reply-To: <CACGw4H5J7Y1aWc5EFfqPaugy5UNrSzg-qS_N7Aoafu9nYA45Pw@mail.gmail.com>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>
	<4F8B0820.7050001@redhat.com>
	<CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>
	<4F8B0C02.6070406@redhat.com>
	<CACGw4H5J7Y1aWc5EFfqPaugy5UNrSzg-qS_N7Aoafu9nYA45Pw@mail.gmail.com>
Message-ID: <4F8BD701.1070204@redhat.com>

On 04/15/2012 07:02 PM, Fernando Cassia wrote:
> On Sun, Apr 15, 2012 at 14:57, Andrew Haley <aph at redhat.com> wrote:
>> If you're going to be rude and sarcastic, I'm going to ignore you.
>> I could help you.  Your call.
> 
> Don't take it personal Andrew. I was just trying to make my point in
> the strongest way possible.
> 
> I can be civil, too.

Excellent, so let's do that.

> It just blows my mind when I see tiny little
> annoyances in FOSS products which arent solved -or even identified as
> problems- because very few people think as an end user.

Me too.  So, let's try to conduct this is a civilized way, as though
we were looking for ways to make free software better, in a spirit of
co-operation.

Andrew.


From aph at redhat.com  Mon Apr 16 01:27:30 2012
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 Apr 2012 09:27:30 +0100
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its name should be openjdk-plugin !
In-Reply-To: <87lilwsule.fsf@mid.deneb.enyo.de>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>
	<4F8B0820.7050001@redhat.com>
	<CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>
	<87lilwsule.fsf@mid.deneb.enyo.de>
Message-ID: <4F8BD7F2.3020207@redhat.com>

On 04/15/2012 07:44 PM, Florian Weimer wrote:
> * Fernando Cassia:
> 
>> So, again, why can't the package now known as Icedtea-web be called
>> "OpenJDK-plugin"?
> 
> Because it's a component which hasn't got to do much with OpenJDK.
> The plugin derives from a separate code base.  Furthermore, Oracle has
> asked the public not to use "OpenJDK" for programs which are not
> substantially the same as something which Oracle publishes under the
> name "OpenJDK".

There is some truth in this: the plugin isn't part of OpenJDK, so it
shouldn't be called openjdk-anything.

> That being said, I'm not even sure if it is a good idea to make the
> plug-in easier to install.  It's the main way the OpenJDK code base is
> exposed to mobile code, after all.

I think this is truly dreadful reasoning.  Either we think that the
plugin is safe enough for people to use, or we don't ship it.

Andrew.


From aph at redhat.com  Mon Apr 16 01:32:23 2012
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 Apr 2012 09:32:23 +0100
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its name should be openjdk-plugin !
In-Reply-To: <CACGw4H5yWav9s92ttbEdJ2CGDf1TO_FW+MV2sefHOHgUvMr72A@mail.gmail.com>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>
	<4F8B0820.7050001@redhat.com>
	<CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>
	<87lilwsule.fsf@mid.deneb.enyo.de>
	<CACGw4H4c+dYKtNFaP+UKJg3ZEtMp0RZGavGRMjvbms9PGJoErg@mail.gmail.com>
	<87aa2cstbv.fsf@mid.deneb.enyo.de>
	<CACGw4H5yWav9s92ttbEdJ2CGDf1TO_FW+MV2sefHOHgUvMr72A@mail.gmail.com>
Message-ID: <4F8BD917.9070500@redhat.com>

On 04/15/2012 08:27 PM, Fernando Cassia wrote:
> On Sun, Apr 15, 2012 at 16:12, Florian Weimer <fw at deneb.enyo.de> wrote:
>> There's a plan to make running browser plugins slightly more
>> difficult: <https://wiki.mozilla.org/Opt-in_activation_for_plugins>
>>
>> Similarly, Microsoft has added a warning to prevent unattended
>> launching of XBAPs.
> 
> Yes, but AFAIK it doesn't extend to making the technologies harder to
> install or to find.
> 
> To enforce that would be a job/problem of the browser.
> 
> Again, my point is making people who install OpenJDK easier to
> find/install the plug-in that goes along with it.
> 
> yum install openjdk7
> currently installs openjdk, but not the plug-in that goes along with
> it (Icedtea)
> whereas if there was a package name-alias (I'm not sure if alias if
> the current term, I suspect so) for Icedtea that matches
> openjdk-plugin, then
> a user typing
> 
> yum install openjdk7*
> 
> ...would automagically pick up OpenJDK, and the plug-in that goes
> along with it, bacause yum would pick up openjdk7, and openjdk7-plugin
> (IcedTea).

Do people do this very often?  I would have thought that people usually
pick packages from a list.

> Of course, in this conservative approach, those who type only "yum
> install openjdk" would get just the OpenJDK and not IcedTea, just as
> happens right now. But the openjdk-plugin alias name to Icedtea would
> greatly increase its visibility, *IMHO*

I don't know that it would.

I don't disagree that it would be much better if it were easier to find
the plugin.  I think it would be best if the browser told people how to
do it.  I'm not convinced that simply calling the plugin openjdk-plugin
would make it easier for many users.  But I am open to persuasion.

Andrew.


From jvanek at redhat.com  Mon Apr 16 02:20:14 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Mon, 16 Apr 2012 11:20:14 +0200
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its name should be openjdk-plugin !
In-Reply-To: <4F8BD917.9070500@redhat.com>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>	<4F8B0820.7050001@redhat.com>	<CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>	<87lilwsule.fsf@mid.deneb.enyo.de>	<CACGw4H4c+dYKtNFaP+UKJg3ZEtMp0RZGavGRMjvbms9PGJoErg@mail.gmail.com>	<87aa2cstbv.fsf@mid.deneb.enyo.de>	<CACGw4H5yWav9s92ttbEdJ2CGDf1TO_FW+MV2sefHOHgUvMr72A@mail.gmail.com>
	<4F8BD917.9070500@redhat.com>
Message-ID: <4F8BE44E.5070003@redhat.com>

On 04/16/2012 10:32 AM, Andrew Haley wrote:
> On 04/15/2012 08:27 PM, Fernando Cassia wrote:
>> On Sun, Apr 15, 2012 at 16:12, Florian Weimer<fw at deneb.enyo.de>  wrote:
...
>> Of course, in this conservative approach, those who type only "yum
>> install openjdk" would get just the OpenJDK and not IcedTea, just as
>> happens right now. But the openjdk-plugin alias name to Icedtea would
>> greatly increase its visibility, *IMHO*
>
> I don't know that it would.
>
> I don't disagree that it would be much better if it were easier to find
> the plugin.  I think it would be best if the browser told people how to
> do it.  I'm not convinced that simply calling the plugin openjdk-plugin
> would make it easier for many users.  But I am open to persuasion.
>

To install icedtea-web together with java-1.x.openjdk is not hard from packager's perspective .... actually why we are not doing it?

J.


From ptisnovs at icedtea.classpath.org  Mon Apr 16 02:25:20 2012
From: ptisnovs at icedtea.classpath.org (ptisnovs at icedtea.classpath.org)
Date: Mon, 16 Apr 2012 09:25:20 +0000
Subject: /hg/gfx-test: 2012-04-16  Pavel Tisnovsky  <ptisnovs@redhat.com>
Message-ID: <hg.31509443dff8.1334568320.-6248649288953172555@icedtea.classpath.org>

changeset 31509443dff8 in /hg/gfx-test
details: http://icedtea.classpath.org/hg/gfx-test?cmd=changeset;node=31509443dff8
author: Pavel Tisnovsky <ptisnovs at redhat.com>
date: Mon Apr 16 11:27:52 2012 +0200

	2012-04-16  Pavel Tisnovsky  <ptisnovs at redhat.com>

		* src/org/gfxtest/testsuites/PrintTestBasic.java:
		Added first print test.
		* Makefile: Updated


diffstat:

 ChangeLog                                      |    6 +
 Makefile                                       |    6 +-
 src/org/gfxtest/testsuites/PrintTestBasic.java |  107 +++++++++++++++++++++++++
 3 files changed, 117 insertions(+), 2 deletions(-)

diffs (147 lines):

diff -r cba2ae48526e -r 31509443dff8 ChangeLog
--- a/ChangeLog	Fri Apr 13 14:15:12 2012 +0200
+++ b/ChangeLog	Mon Apr 16 11:27:52 2012 +0200
@@ -1,3 +1,9 @@
+2012-04-16  Pavel Tisnovsky  <ptisnovs at redhat.com>
+
+	* src/org/gfxtest/testsuites/PrintTestBasic.java:
+	Added first print test.
+	* Makefile: Updated
+
 2012-04-13  Pavel Tisnovsky  <ptisnovs at redhat.com>
 
 	* src/org/gfxtest/framework/GfxTest.java:
diff -r cba2ae48526e -r 31509443dff8 Makefile
--- a/Makefile	Fri Apr 13 14:15:12 2012 +0200
+++ b/Makefile	Mon Apr 16 11:27:52 2012 +0200
@@ -172,7 +172,8 @@
 	$(CLASSES)/$(TESTSUITE_DIR)/ClippingPathByConvexPolygonalShape.class \
 	$(CLASSES)/$(TESTSUITE_DIR)/ClippingPathByConcavePolygonalShape.class \
 	$(CLASSES)/$(TESTSUITE_DIR)/ClippingPathBySelfIntersectingPolygonalShape.class \
-	$(CLASSES)/$(TESTSUITE_DIR)/ClippingPathByRoundRectangleShape.class
+	$(CLASSES)/$(TESTSUITE_DIR)/ClippingPathByRoundRectangleShape.class \
+	$(CLASSES)/$(TESTSUITE_DIR)/PrintTestBasic.class
 
 COMPARE_RESULTS = \
 	$(RESULTS)/Areas \
@@ -243,7 +244,8 @@
 	$(RESULTS)/ClippingPathByConcavePolygonalShape \
 	$(RESULTS)/ClippingPathBySelfIntersectingPolygonalShape \
 	$(RESULTS)/ClippingPathByRoundRectangleShape \
-	$(RESULTS)/ClippingPathByRectangleShape
+	$(RESULTS)/ClippingPathByRectangleShape \
+	$(RESULTS)/PrintTestBasic
 
 # targets for all test suites
 TESTSUITES = $(shell ls -1 src/org/gfxtest/testsuites | sed -n -e 's/\([A-Za-z0-9]*\)\.java/\1/p')
diff -r cba2ae48526e -r 31509443dff8 src/org/gfxtest/testsuites/PrintTestBasic.java
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/src/org/gfxtest/testsuites/PrintTestBasic.java	Mon Apr 16 11:27:52 2012 +0200
@@ -0,0 +1,107 @@
+/*
+  Java gfx-test framework
+
+   Copyright (C) 2010, 2011, 2012  Red Hat
+
+This file is part of IcedTea.
+
+IcedTea is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+IcedTea is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with IcedTea; see the file COPYING.  If not, write to the
+Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+02110-1301 USA.
+
+Linking this library statically or dynamically with other modules is
+making a combined work based on this library.  Thus, the terms and
+conditions of the GNU General Public License cover the whole
+combination.
+
+As a special exception, the copyright holders of this library give you
+permission to link this library with independent modules to produce an
+executable, regardless of the license terms of these independent
+modules, and to copy and distribute the resulting executable under
+terms of your choice, provided that you also meet, for each linked
+independent module, the terms and conditions of the license of that
+module.  An independent module is a module which is not derived from
+or based on this library.  If you modify this library, you may extend
+this exception to your version of the library, but you are not
+obligated to do so.  If you do not wish to do so, delete this
+exception statement from your version.
+*/
+
+package org.gfxtest.testsuites;
+
+import java.awt.Color;
+import java.awt.Graphics2D;
+
+
+
+import org.gfxtest.framework.GfxTest;
+import org.gfxtest.framework.TestImage;
+import org.gfxtest.framework.TestResult;
+import org.gfxtest.framework.annotations.GraphicsPrimitive;
+import org.gfxtest.framework.annotations.GraphicsPrimitives;
+import org.gfxtest.framework.annotations.RenderStyle;
+import org.gfxtest.framework.annotations.RenderStyles;
+import org.gfxtest.framework.annotations.TestType;
+import org.gfxtest.framework.annotations.TestTypes;
+import org.gfxtest.framework.annotations.Transformation;
+import org.gfxtest.framework.annotations.Transformations;
+import org.gfxtest.framework.annotations.Zoom;
+
+
+
+/**
+ * This test suite checks basic functionality of built-in printing support.
+ * 
+ * @author Pavel Tisnovsky
+ */
+ at TestType(TestTypes.PRINT_TEST)
+ at GraphicsPrimitive(GraphicsPrimitives.LINE)
+ at RenderStyle(RenderStyles.NORMAL)
+ at Transformation(Transformations.NONE)
+ at Zoom(1)
+public class PrintTestBasic extends GfxTest
+{
+
+    /**
+     * Test basic behavior of method Graphics.drawLine().
+     *
+     * @param image
+     *            image to which line is to be drawn
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testDrawLine(TestImage image, Graphics2D graphics)
+    {
+        // set drawing color
+        graphics.setColor(Color.BLACK);
+
+        // draw two diagonals along the whole test image
+        graphics.drawLine(0, 0, image.getWidth(), image.getHeight());
+        graphics.drawLine(0, image.getHeight(), image.getWidth(), 0);
+
+        // test return value
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Entry point to the test suite.
+     *
+     * @param args not used in this case
+     */
+    public static void main(String[] args)
+    {
+        new PrintTestBasic().runTestSuite(args);
+    }
+}


From aph at redhat.com  Mon Apr 16 02:31:16 2012
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 Apr 2012 10:31:16 +0100
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its name should be openjdk-plugin !
In-Reply-To: <4F8BE44E.5070003@redhat.com>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>	<4F8B0820.7050001@redhat.com>	<CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>	<87lilwsule.fsf@mid.deneb.enyo.de>	<CACGw4H4c+dYKtNFaP+UKJg3ZEtMp0RZGavGRMjvbms9PGJoErg@mail.gmail.com>	<87aa2cstbv.fsf@mid.deneb.enyo.de>	<CACGw4H5yWav9s92ttbEdJ2CGDf1TO_FW+MV2sefHOHgUvMr72A@mail.gmail.com>
	<4F8BD917.9070500@redhat.com> <4F8BE44E.5070003@redhat.com>
Message-ID: <4F8BE6E4.7090609@redhat.com>

On 04/16/2012 10:20 AM, Jiri Vanek wrote:
> On 04/16/2012 10:32 AM, Andrew Haley wrote:
>> On 04/15/2012 08:27 PM, Fernando Cassia wrote:
>>> On Sun, Apr 15, 2012 at 16:12, Florian Weimer<fw at deneb.enyo.de>  wrote:
> ...
>>> Of course, in this conservative approach, those who type only "yum
>>> install openjdk" would get just the OpenJDK and not IcedTea, just as
>>> happens right now. But the openjdk-plugin alias name to Icedtea would
>>> greatly increase its visibility, *IMHO*
>>
>> I don't know that it would.
>>
>> I don't disagree that it would be much better if it were easier to find
>> the plugin.  I think it would be best if the browser told people how to
>> do it.  I'm not convinced that simply calling the plugin openjdk-plugin
>> would make it easier for many users.  But I am open to persuasion.
> 
> To install icedtea-web together with java-1.x.openjdk is not hard
> from packager's perspective .... actually why we are not doing it?

What exactly would you do?  Make openjdk depend on the plugin?  A
virtual package that depended on bot?  Or... ?

Andrew.


From aph at redhat.com  Mon Apr 16 02:48:16 2012
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 Apr 2012 10:48:16 +0100
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its name should be openjdk-plugin !
In-Reply-To: <4F8BE6E4.7090609@redhat.com>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>	<4F8B0820.7050001@redhat.com>	<CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>	<87lilwsule.fsf@mid.deneb.enyo.de>	<CACGw4H4c+dYKtNFaP+UKJg3ZEtMp0RZGavGRMjvbms9PGJoErg@mail.gmail.com>	<87aa2cstbv.fsf@mid.deneb.enyo.de>	<CACGw4H5yWav9s92ttbEdJ2CGDf1TO_FW+MV2sefHOHgUvMr72A@mail.gmail.com>
	<4F8BD917.9070500@redhat.com> <4F8BE44E.5070003@redhat.com>
	<4F8BE6E4.7090609@redhat.com>
Message-ID: <4F8BEAE0.4060303@redhat.com>

On 04/16/2012 10:31 AM, Andrew Haley wrote:
> On 04/16/2012 10:20 AM, Jiri Vanek wrote:
>> On 04/16/2012 10:32 AM, Andrew Haley wrote:
>>> On 04/15/2012 08:27 PM, Fernando Cassia wrote:
>>>> On Sun, Apr 15, 2012 at 16:12, Florian Weimer<fw at deneb.enyo.de>  wrote:
>> ...
>>>> Of course, in this conservative approach, those who type only "yum
>>>> install openjdk" would get just the OpenJDK and not IcedTea, just as
>>>> happens right now. But the openjdk-plugin alias name to Icedtea would
>>>> greatly increase its visibility, *IMHO*
>>>
>>> I don't know that it would.
>>>
>>> I don't disagree that it would be much better if it were easier to find
>>> the plugin.  I think it would be best if the browser told people how to
>>> do it.  I'm not convinced that simply calling the plugin openjdk-plugin
>>> would make it easier for many users.  But I am open to persuasion.
>>
>> To install icedtea-web together with java-1.x.openjdk is not hard
>> from packager's perspective .... actually why we are not doing it?
> 
> What exactly would you do?  Make openjdk depend on the plugin?  A
> virtual package that depended on bot?  Or... ?

Err, depended on both...

> 
> Andrew.



From bugzilla-daemon at icedtea.classpath.org  Mon Apr 16 02:51:21 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Mon, 16 Apr 2012 09:51:21 +0000
Subject: [Bug 797] Compiler error message does not display entire file name
	and path
In-Reply-To: <bug-797-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-797-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-797-30-YnF2Z9a3A6@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=797

Pavel Tisnovsky <ptisnovs at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ptisnovs at redhat.com

--- Comment #2 from Pavel Tisnovsky <ptisnovs at redhat.com> 2012-04-16 09:51:21 UTC ---
I've tried it with freshly build IcedTea6-1.11

jawa16:~/icedtea6-1.11/openjdk.build/j2sdk-image/bin/$ ./java -version
java version "1.6.0_24"
OpenJDK Runtime Environment (IcedTea6 1.11.2pre+ra134afa67a3f)
(RedHatEnterpriseServer build 1.6.0_24-b24)
OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)

With following results:

jawa16:~/icedtea6-1.11/openjdk.build/j2sdk-image/bin/$ ./javac src/t.java 
src/t.java:1: cannot find symbol
^^^^^^^^^^^^
symbol  : variable a
location: class t
public class t{ static {System.out.println(a);}}
                                           ^
1 error

For the test file t.java:

public class t{ static {System.out.println(a);}}

Is it the required behavior?

-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


From jvanek at redhat.com  Mon Apr 16 03:06:46 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Mon, 16 Apr 2012 12:06:46 +0200
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its name should be openjdk-plugin !
In-Reply-To: <4F8BE6E4.7090609@redhat.com>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>	<4F8B0820.7050001@redhat.com>	<CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>	<87lilwsule.fsf@mid.deneb.enyo.de>	<CACGw4H4c+dYKtNFaP+UKJg3ZEtMp0RZGavGRMjvbms9PGJoErg@mail.gmail.com>	<87aa2cstbv.fsf@mid.deneb.enyo.de>	<CACGw4H5yWav9s92ttbEdJ2CGDf1TO_FW+MV2sefHOHgUvMr72A@mail.gmail.com>
	<4F8BD917.9070500@redhat.com> <4F8BE44E.5070003@redhat.com>
	<4F8BE6E4.7090609@redhat.com>
Message-ID: <4F8BEF36.2060402@redhat.com>

On 04/16/2012 11:31 AM, Andrew Haley wrote:
> On 04/16/2012 10:20 AM, Jiri Vanek wrote:
>> On 04/16/2012 10:32 AM, Andrew Haley wrote:
>>> On 04/15/2012 08:27 PM, Fernando Cassia wrote:
>>>> On Sun, Apr 15, 2012 at 16:12, Florian Weimer<fw at deneb.enyo.de>   wrote:
>> ...
>>>> Of course, in this conservative approach, those who type only "yum
>>>> install openjdk" would get just the OpenJDK and not IcedTea, just as
>>>> happens right now. But the openjdk-plugin alias name to Icedtea would
>>>> greatly increase its visibility, *IMHO*
>>>
>>> I don't know that it would.
>>>
>>> I don't disagree that it would be much better if it were easier to find
>>> the plugin.  I think it would be best if the browser told people how to
>>> do it.  I'm not convinced that simply calling the plugin openjdk-plugin
>>> would make it easier for many users.  But I am open to persuasion.
>>
>> To install icedtea-web together with java-1.x.openjdk is not hard
>> from packager's perspective .... actually why we are not doing it?
>
> What exactly would you do?  Make openjdk depend on the plugin?  A
> virtual package that depended on both?  Or... ?
>
Well metapackage can solve a lot, but it is to much effort which I don't think is worthy. But yes, it is option.
To install icedtea-web together with java without unnecessary circular dependences is eg to make java-1.x-0-openjdk postin dependent on icedtea-web. My talk with local packagers about this topic ("logical dependence") was just short one and maybe there is cleaner solution. But this should help too.


J.



From aph at redhat.com  Mon Apr 16 03:19:58 2012
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 Apr 2012 11:19:58 +0100
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its name should be openjdk-plugin !
In-Reply-To: <4F8BEF36.2060402@redhat.com>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>	<4F8B0820.7050001@redhat.com>	<CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>	<87lilwsule.fsf@mid.deneb.enyo.de>	<CACGw4H4c+dYKtNFaP+UKJg3ZEtMp0RZGavGRMjvbms9PGJoErg@mail.gmail.com>	<87aa2cstbv.fsf@mid.deneb.enyo.de>	<CACGw4H5yWav9s92ttbEdJ2CGDf1TO_FW+MV2sefHOHgUvMr72A@mail.gmail.com>
	<4F8BD917.9070500@redhat.com> <4F8BE44E.5070003@redhat.com>
	<4F8BE6E4.7090609@redhat.com> <4F8BEF36.2060402@redhat.com>
Message-ID: <4F8BF24E.5050603@redhat.com>

On 04/16/2012 11:06 AM, Jiri Vanek wrote:
> On 04/16/2012 11:31 AM, Andrew Haley wrote:
>> On 04/16/2012 10:20 AM, Jiri Vanek wrote:
>>> On 04/16/2012 10:32 AM, Andrew Haley wrote:
>>>> On 04/15/2012 08:27 PM, Fernando Cassia wrote:
>>>>> On Sun, Apr 15, 2012 at 16:12, Florian Weimer<fw at deneb.enyo.de>   wrote:
>>> ...
>>>>> Of course, in this conservative approach, those who type only "yum
>>>>> install openjdk" would get just the OpenJDK and not IcedTea, just as
>>>>> happens right now. But the openjdk-plugin alias name to Icedtea would
>>>>> greatly increase its visibility, *IMHO*
>>>>
>>>> I don't know that it would.
>>>>
>>>> I don't disagree that it would be much better if it were easier to find
>>>> the plugin.  I think it would be best if the browser told people how to
>>>> do it.  I'm not convinced that simply calling the plugin openjdk-plugin
>>>> would make it easier for many users.  But I am open to persuasion.
>>>
>>> To install icedtea-web together with java-1.x.openjdk is not hard
>>> from packager's perspective .... actually why we are not doing it?
>>
>> What exactly would you do?  Make openjdk depend on the plugin?  A
>> virtual package that depended on both?  Or... ?
>>
> Well metapackage can solve a lot, but it is to much effort which I
> don't think is worthy. But yes, it is option.
>
> To install icedtea-web together with java without unnecessary
> circular dependences is eg to make java-1.x-0-openjdk postin
> dependent on icedtea-web. My talk with local packagers about this
> topic ("logical dependence") was just short one and maybe there is
> cleaner solution. But this should help too.

Err, but that would make people install the plugin if they only wanted
Java, wouldn't it?  I don't want that.

Andrew.




From jvanek at redhat.com  Mon Apr 16 03:27:01 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Mon, 16 Apr 2012 12:27:01 +0200
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its name should be openjdk-plugin !
In-Reply-To: <4F8BF24E.5050603@redhat.com>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>	<4F8B0820.7050001@redhat.com>	<CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>	<87lilwsule.fsf@mid.deneb.enyo.de>	<CACGw4H4c+dYKtNFaP+UKJg3ZEtMp0RZGavGRMjvbms9PGJoErg@mail.gmail.com>	<87aa2cstbv.fsf@mid.deneb.enyo.de>	<CACGw4H5yWav9s92ttbEdJ2CGDf1TO_FW+MV2sefHOHgUvMr72A@mail.gmail.com>
	<4F8BD917.9070500@redhat.com> <4F8BE44E.5070003@redhat.com>
	<4F8BE6E4.7090609@redhat.com> <4F8BEF36.2060402@redhat.com>
	<4F8BF24E.5050603@redhat.com>
Message-ID: <4F8BF3F5.7070409@redhat.com>

On 04/16/2012 12:19 PM, Andrew Haley wrote:
> On 04/16/2012 11:06 AM, Jiri Vanek wrote:
>> On 04/16/2012 11:31 AM, Andrew Haley wrote:
>>> On 04/16/2012 10:20 AM, Jiri Vanek wrote:
>>>> On 04/16/2012 10:32 AM, Andrew Haley wrote:
>>>>> On 04/15/2012 08:27 PM, Fernando Cassia wrote:
>>>>>> On Sun, Apr 15, 2012 at 16:12, Florian Weimer<fw at deneb.enyo.de>    wrote:
>>>> ...
>>>>>> Of course, in this conservative approach, those who type only "yum
>>>>>> install openjdk" would get just the OpenJDK and not IcedTea, just as
>>>>>> happens right now. But the openjdk-plugin alias name to Icedtea would
>>>>>> greatly increase its visibility, *IMHO*
>>>>>
>>>>> I don't know that it would.
>>>>>
>>>>> I don't disagree that it would be much better if it were easier to find
>>>>> the plugin.  I think it would be best if the browser told people how to
>>>>> do it.  I'm not convinced that simply calling the plugin openjdk-plugin
>>>>> would make it easier for many users.  But I am open to persuasion.
>>>>
>>>> To install icedtea-web together with java-1.x.openjdk is not hard
>>>> from packager's perspective .... actually why we are not doing it?
>>>
>>> What exactly would you do?  Make openjdk depend on the plugin?  A
>>> virtual package that depended on both?  Or... ?
>>>
>> Well metapackage can solve a lot, but it is to much effort which I
>> don't think is worthy. But yes, it is option.
>>
>> To install icedtea-web together with java without unnecessary
>> circular dependences is eg to make java-1.x-0-openjdk postin
>> dependent on icedtea-web. My talk with local packagers about this
>> topic ("logical dependence") was just short one and maybe there is
>> cleaner solution. But this should help too.
>
> Err, but that would make people install the plugin if they only wanted
> Java, wouldn't it?  I don't want that.
Yes, it will.
If you do not want, then I think we are done here :)

And because I'm definitely against renaming or against wrapping java-plugin package, then it looks like I'm done to.

Lets see what guys from CA will think about whole this "issue".


J.



From aph at redhat.com  Mon Apr 16 03:27:23 2012
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 Apr 2012 11:27:23 +0100
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its name should be openjdk-plugin !
In-Reply-To: <4F8BF3F5.7070409@redhat.com>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>	<4F8B0820.7050001@redhat.com>	<CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>	<87lilwsule.fsf@mid.deneb.enyo.de>	<CACGw4H4c+dYKtNFaP+UKJg3ZEtMp0RZGavGRMjvbms9PGJoErg@mail.gmail.com>	<87aa2cstbv.fsf@mid.deneb.enyo.de>	<CACGw4H5yWav9s92ttbEdJ2CGDf1TO_FW+MV2sefHOHgUvMr72A@mail.gmail.com>
	<4F8BD917.9070500@redhat.com> <4F8BE44E.5070003@redhat.com>
	<4F8BE6E4.7090609@redhat.com> <4F8BEF36.2060402@redhat.com>
	<4F8BF24E.5050603@redhat.com> <4F8BF3F5.7070409@redhat.com>
Message-ID: <4F8BF40B.3000801@redhat.com>

On 04/16/2012 11:27 AM, Jiri Vanek wrote:
> On 04/16/2012 12:19 PM, Andrew Haley wrote:
>> On 04/16/2012 11:06 AM, Jiri Vanek wrote:
>>> On 04/16/2012 11:31 AM, Andrew Haley wrote:
>>>> On 04/16/2012 10:20 AM, Jiri Vanek wrote:
>>>>> On 04/16/2012 10:32 AM, Andrew Haley wrote:
>>>>>> On 04/15/2012 08:27 PM, Fernando Cassia wrote:
>>>>>>> On Sun, Apr 15, 2012 at 16:12, Florian Weimer<fw at deneb.enyo.de>    wrote:
>>>>> ...
>>>>>>> Of course, in this conservative approach, those who type only "yum
>>>>>>> install openjdk" would get just the OpenJDK and not IcedTea, just as
>>>>>>> happens right now. But the openjdk-plugin alias name to Icedtea would
>>>>>>> greatly increase its visibility, *IMHO*
>>>>>>
>>>>>> I don't know that it would.
>>>>>>
>>>>>> I don't disagree that it would be much better if it were easier to find
>>>>>> the plugin.  I think it would be best if the browser told people how to
>>>>>> do it.  I'm not convinced that simply calling the plugin openjdk-plugin
>>>>>> would make it easier for many users.  But I am open to persuasion.
>>>>>
>>>>> To install icedtea-web together with java-1.x.openjdk is not hard
>>>>> from packager's perspective .... actually why we are not doing it?
>>>>
>>>> What exactly would you do?  Make openjdk depend on the plugin?  A
>>>> virtual package that depended on both?  Or... ?
>>>>
>>> Well metapackage can solve a lot, but it is to much effort which I
>>> don't think is worthy. But yes, it is option.
>>>
>>> To install icedtea-web together with java without unnecessary
>>> circular dependences is eg to make java-1.x-0-openjdk postin
>>> dependent on icedtea-web. My talk with local packagers about this
>>> topic ("logical dependence") was just short one and maybe there is
>>> cleaner solution. But this should help too.
>>
>> Err, but that would make people install the plugin if they only wanted
>> Java, wouldn't it?  I don't want that.
>
> Yes, it will.
> If you do not want, then I think we are done here :)
> 
> And because I'm definitely against renaming or against wrapping java-plugin package, then it looks like I'm done to.

Well, requires are supposed to mean that Package X requires Package Y
to run.  I don't think much good will come from lying to the packaging
system (and the user).

> Lets see what guys from CA will think about whole this "issue".

CA ?

Andrew.



From fcassia at gmail.com  Mon Apr 16 03:27:45 2012
From: fcassia at gmail.com (Fernando Cassia)
Date: Mon, 16 Apr 2012 07:27:45 -0300
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream, its
	name should be openjdk-plugin !
In-Reply-To: <4F8BD7F2.3020207@redhat.com>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>
	<4F8B0820.7050001@redhat.com>
	<CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>
	<87lilwsule.fsf@mid.deneb.enyo.de> <4F8BD7F2.3020207@redhat.com>
Message-ID: <CACGw4H4OE03-nJBYju0hrNP+gnhz-x691VsZOZYNZ=X7WiduDA@mail.gmail.com>

On Mon, Apr 16, 2012 at 05:27, Andrew Haley <aph at redhat.com> wrote:

> I think this is truly dreadful reasoning.  Either we think that the
> plugin is safe enough for people to use, or we don't ship it.
>
> Andrew.
>

+1

:)

FC
-- 
During times of Universal Deceit, telling the truth becomes a revolutionary
act
- George Orwell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120416/36611503/attachment.html 

From fcassia at gmail.com  Mon Apr 16 03:31:06 2012
From: fcassia at gmail.com (Fernando Cassia)
Date: Mon, 16 Apr 2012 07:31:06 -0300
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream, its
	name should be openjdk-plugin !
In-Reply-To: <4F8BE6E4.7090609@redhat.com>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>
	<4F8B0820.7050001@redhat.com>
	<CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>
	<87lilwsule.fsf@mid.deneb.enyo.de>
	<CACGw4H4c+dYKtNFaP+UKJg3ZEtMp0RZGavGRMjvbms9PGJoErg@mail.gmail.com>
	<87aa2cstbv.fsf@mid.deneb.enyo.de>
	<CACGw4H5yWav9s92ttbEdJ2CGDf1TO_FW+MV2sefHOHgUvMr72A@mail.gmail.com>
	<4F8BD917.9070500@redhat.com> <4F8BE44E.5070003@redhat.com>
	<4F8BE6E4.7090609@redhat.com>
Message-ID: <CACGw4H4K+oyHR9jeLoqnsQbGCtSPig-FbpbdxY85FEiWyD01kg@mail.gmail.com>

On Mon, Apr 16, 2012 at 06:31, Andrew Haley <aph at redhat.com> wrote:

> What exactly would you do?  Make openjdk depend on the plugin?  A
> virtual package that depended on bot?  Or... ?
>

My view was not making openjdk depend on the plug-in, just a renaming so
"yum install openjdk7*" would pick openjdk (the jvm) and openjdk-plugin.
Notice the asterisk.

Also people looking for "openJDK" on the graphical package managers would
see not only the JVM but also the plug-in.

But, of course, people who just do a "yum install openjdk" would get only
the jvm, not the plug-in.
It think this is a middle ground that would please almost everyone.

FC

-- 
During times of Universal Deceit, telling the truth becomes a revolutionary
act
Durante ?pocas de Enga?o Universal, decir la verdad se convierte en un Acto
Revolucionario
- George Orwell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120416/b5091e36/attachment.html 

From fcassia at gmail.com  Mon Apr 16 03:33:12 2012
From: fcassia at gmail.com (Fernando Cassia)
Date: Mon, 16 Apr 2012 07:33:12 -0300
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream, its
	name should be openjdk-plugin !
In-Reply-To: <4F8BD917.9070500@redhat.com>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>
	<4F8B0820.7050001@redhat.com>
	<CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>
	<87lilwsule.fsf@mid.deneb.enyo.de>
	<CACGw4H4c+dYKtNFaP+UKJg3ZEtMp0RZGavGRMjvbms9PGJoErg@mail.gmail.com>
	<87aa2cstbv.fsf@mid.deneb.enyo.de>
	<CACGw4H5yWav9s92ttbEdJ2CGDf1TO_FW+MV2sefHOHgUvMr72A@mail.gmail.com>
	<4F8BD917.9070500@redhat.com>
Message-ID: <CACGw4H412erJAhtRnV0KdtRF913bZXjJef2Wh9mDbEjGVVkWLw@mail.gmail.com>

On Mon, Apr 16, 2012 at 05:32, Andrew Haley <aph at redhat.com> wrote:

> I'm not convinced that simply calling the plugin openjdk-plugin
> would make it easier for many users.  But I am open to persuasion.
>

Yes it would help. In two instances:

When you do 'yum install openjdk7* '  to install all packages with names
beginning with "openjdk7..."
And also for users who search for packages by name on the GUIs for package
managers (ie Fedora's Add-Remove programs)

Just my $0.02.

FC
-- 
During times of Universal Deceit, telling the truth becomes a revolutionary
act
- George Orwell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120416/819d5a8f/attachment.html 

From fcassia at gmail.com  Mon Apr 16 03:37:38 2012
From: fcassia at gmail.com (Fernando Cassia)
Date: Mon, 16 Apr 2012 07:37:38 -0300
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream, its
	name should be openjdk-plugin !
In-Reply-To: <20120416073159.GB21928@toonder.wildebeest.org>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>
	<20120416073159.GB21928@toonder.wildebeest.org>
Message-ID: <CACGw4H4Y-=pr96X3-8hu8Zr5bkc99SPpdbY69mZ1ih4TEwF_dA@mail.gmail.com>

On Mon, Apr 16, 2012 at 04:31, Mark Wielaard <mark at klomp.org> wrote:

> Oracle has decided to take a trademark
> on OpenJDK
>

Makes sense to me. As does Firefox.


>  they allow distros to call IcedTea (in certain configurations)
> OpenJDK,
>

This is news to me. Which for instance?


> but they don't allow this for IcedTea-Web.
>

Is this written somewhere?. If the package is still called "Icedtea" but
comes with a 'meta package' (empty package) named openjdk-plugin and
referencing icedtea, wouldn' t that fit the bill? (as you haven't renamed
Icedtea-web, just created a pointer to it).

Thinking aloud...
FC


> Please go ask them
> if you want them to clean up their trademark license to allow this.
>



-- 
During times of Universal Deceit, telling the truth becomes a revolutionary
act
Durante ?pocas de Enga?o Universal, decir la verdad se convierte en un Acto
Revolucionario
- George Orwell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120416/145519c6/attachment.html 

From aph at redhat.com  Mon Apr 16 03:37:40 2012
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 Apr 2012 11:37:40 +0100
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its name should be openjdk-plugin !
In-Reply-To: <CACGw4H4K+oyHR9jeLoqnsQbGCtSPig-FbpbdxY85FEiWyD01kg@mail.gmail.com>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>
	<4F8B0820.7050001@redhat.com>
	<CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>
	<87lilwsule.fsf@mid.deneb.enyo.de>
	<CACGw4H4c+dYKtNFaP+UKJg3ZEtMp0RZGavGRMjvbms9PGJoErg@mail.gmail.com>
	<87aa2cstbv.fsf@mid.deneb.enyo.de>
	<CACGw4H5yWav9s92ttbEdJ2CGDf1TO_FW+MV2sefHOHgUvMr72A@mail.gmail.com>
	<4F8BD917.9070500@redhat.com> <4F8BE44E.5070003@redhat.com>
	<4F8BE6E4.7090609@redhat.com>
	<CACGw4H4K+oyHR9jeLoqnsQbGCtSPig-FbpbdxY85FEiWyD01kg@mail.gmail.com>
Message-ID: <4F8BF674.4020809@redhat.com>

On 04/16/2012 11:31 AM, Fernando Cassia wrote:
> On Mon, Apr 16, 2012 at 06:31, Andrew Haley <aph at redhat.com> wrote:
> 
>> What exactly would you do?  Make openjdk depend on the plugin?  A
>> virtual package that depended on bot?  Or... ?
> 
> My view was not making openjdk depend on the plug-in, just a renaming so
> "yum install openjdk7*" would pick openjdk (the jvm) and openjdk-plugin.
> Notice the asterisk.
> 
> Also people looking for "openJDK" on the graphical package managers would
> see not only the JVM but also the plug-in.
> 
> But, of course, people who just do a "yum install openjdk" would get only
> the jvm, not the plug-in.
> It think this is a middle ground that would please almost everyone.

Maybe, but I am worried that calling the plugin package openjdk-plugin
would be misleading: the plugin isn't part of OpenJDK.  And, you might
reply that the user doesn't care; but the stakeholders in OpenJDK (or
at least some of them) do care.  I'm trying to think of a way around
this problem.

Andrew.


From fcassia at gmail.com  Mon Apr 16 03:39:06 2012
From: fcassia at gmail.com (Fernando Cassia)
Date: Mon, 16 Apr 2012 07:39:06 -0300
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream, its
	name should be openjdk-plugin !
In-Reply-To: <4F8BF674.4020809@redhat.com>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>
	<4F8B0820.7050001@redhat.com>
	<CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>
	<87lilwsule.fsf@mid.deneb.enyo.de>
	<CACGw4H4c+dYKtNFaP+UKJg3ZEtMp0RZGavGRMjvbms9PGJoErg@mail.gmail.com>
	<87aa2cstbv.fsf@mid.deneb.enyo.de>
	<CACGw4H5yWav9s92ttbEdJ2CGDf1TO_FW+MV2sefHOHgUvMr72A@mail.gmail.com>
	<4F8BD917.9070500@redhat.com> <4F8BE44E.5070003@redhat.com>
	<4F8BE6E4.7090609@redhat.com>
	<CACGw4H4K+oyHR9jeLoqnsQbGCtSPig-FbpbdxY85FEiWyD01kg@mail.gmail.com>
	<4F8BF674.4020809@redhat.com>
Message-ID: <CACGw4H6-e=67ZkdwDfj4S9fMNO5Ptb-rDi4hTmtO7W9O6FaFsA@mail.gmail.com>

On Mon, Apr 16, 2012 at 07:37, Andrew Haley <aph at redhat.com> wrote:

> Maybe, but I am worried that calling the plugin package openjdk-plugin
> would be misleading: the plugin isn't part of OpenJDK.  And, you might
> reply that the user doesn't care; but the stakeholders in OpenJDK (or
> at least some of them) do care.  I'm trying to think of a way around
> this problem.
>

Who in the OpenJDK team would be interested in discussing this?
Any ideas?

Regards,
FC

-- 
During times of Universal Deceit, telling the truth becomes a revolutionary
act
- George Orwell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120416/58e20d64/attachment.html 

From aph at redhat.com  Mon Apr 16 03:40:30 2012
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 Apr 2012 11:40:30 +0100
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its name should be openjdk-plugin !
In-Reply-To: <CACGw4H6-e=67ZkdwDfj4S9fMNO5Ptb-rDi4hTmtO7W9O6FaFsA@mail.gmail.com>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>
	<4F8B0820.7050001@redhat.com>
	<CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>
	<87lilwsule.fsf@mid.deneb.enyo.de>
	<CACGw4H4c+dYKtNFaP+UKJg3ZEtMp0RZGavGRMjvbms9PGJoErg@mail.gmail.com>
	<87aa2cstbv.fsf@mid.deneb.enyo.de>
	<CACGw4H5yWav9s92ttbEdJ2CGDf1TO_FW+MV2sefHOHgUvMr72A@mail.gmail.com>
	<4F8BD917.9070500@redhat.com> <4F8BE44E.5070003@redhat.com>
	<4F8BE6E4.7090609@redhat.com>
	<CACGw4H4K+oyHR9jeLoqnsQbGCtSPig-FbpbdxY85FEiWyD01kg@mail.gmail.com>
	<4F8BF674.4020809@redhat.com>
	<CACGw4H6-e=67ZkdwDfj4S9fMNO5Ptb-rDi4hTmtO7W9O6FaFsA@mail.gmail.com>
Message-ID: <4F8BF71E.8020601@redhat.com>

On 04/16/2012 11:39 AM, Fernando Cassia wrote:
> On Mon, Apr 16, 2012 at 07:37, Andrew Haley <aph at redhat.com> wrote:
> 
>> Maybe, but I am worried that calling the plugin package openjdk-plugin
>> would be misleading: the plugin isn't part of OpenJDK.  And, you might
>> reply that the user doesn't care; but the stakeholders in OpenJDK (or
>> at least some of them) do care.  I'm trying to think of a way around
>> this problem.
> 
> Who in the OpenJDK team would be interested in discussing this?
> Any ideas?

Me.  I am, among other things, a member of the OpenJDK Governing
Board.

Andrew.


From mark at klomp.org  Mon Apr 16 04:05:25 2012
From: mark at klomp.org (Mark Wielaard)
Date: Mon, 16 Apr 2012 13:05:25 +0200
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its name should be openjdk-plugin !
In-Reply-To: <CACGw4H4Y-=pr96X3-8hu8Zr5bkc99SPpdbY69mZ1ih4TEwF_dA@mail.gmail.com>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>
	<20120416073159.GB21928@toonder.wildebeest.org>
	<CACGw4H4Y-=pr96X3-8hu8Zr5bkc99SPpdbY69mZ1ih4TEwF_dA@mail.gmail.com>
Message-ID: <1334574325.2986.9.camel@springer.wildebeest.org>

On Mon, 2012-04-16 at 07:37 -0300, Fernando Cassia wrote:

>          they allow distros to call IcedTea (in certain
>         configurations)
>         OpenJDK,
> 
> This is news to me. Which for instance?
>  
>         but they don't allow this for IcedTea-Web.
> 
> Is this written somewhere?
>
>         Please go ask them
>         if you want them to clean up their trademark license to allow
>         this.

Sure. Here: http://openjdk.java.net/legal/openjdk-trademark-notice.html

You can show that to the distro packagers and discuss with them how/if
they are allowed to handle naming of various components.

Mark Reinhold contributed a patch some time ago to IcedTea to make it
comply with that trademark license and only call it OpenJDK if it was
configured "in the right way", which has been integrated.
http://thread.gmane.org/gmane.comp.java.openjdk.distro-packaging.devel/4863

Cheers,

Mark


From jvanek at redhat.com  Mon Apr 16 04:19:16 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Mon, 16 Apr 2012 13:19:16 +0200
Subject: [rfc] [icedtea-web] make links
Message-ID: <4F8C0034.1080308@redhat.com>

can I dare to ping? :)

-------- Original Message --------
Subject: [rfc] [icedtea-web] make links
Date: Fri, 06 Apr 2012 16:55:04 +0200
From: Jiri Vanek <jvanek at redhat.com>
To: IcedTea Distro List <distro-pkg-dev at openjdk.java.net>

Hi!

This is third from total of 5 patches which are introducing Tets For Applets[1]

This particular one is introducing  detection of browsers, linking the newly compiled plugin to
detected ones and forwarding this information to testengine..

I know this linking by makefile is controversial, but it gives sense to me.
Yes  - I can link the plugin with browsers manually before tests' run (and yes, this can be done
once for all the runs in future), but I think this is much more versatile and is much more
straightforward and much better controllable and also more fool-proof. The question weather to
*UNlink* is more accurate:) ( there is no unlink right now, but should be easily addable if requested.
Also when tests are run from makefile, then also all the possible preparation should be done from
makefile. And this step is necessary. I have also introduced test weather linking is correct see
private void testBrowser(Browser browser) calls in [2]

What I'm missing is When I have choose AC_CHECK_PROGS, then it does not support --with-val :-/ Is
there any AC_CHECK_PROGS which allows to set with-val?
Becasue I will probably put rather --with-firefox=/my/preconfiguired/firefox instead of let it use
my default one. Although Lynks is quite good alternative during tests runtime :)
Also this can be maybe intorduced as new patch later.

Best regards J.

[1] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-March/017799.html
[2]
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120320/8ef6bdfe/browserTests-tests-0001.diff
(btw, this page is partially corrupted - there is html test, and firefox is trying to translate it
as html page :-/.. so see source rather :-/)


changelog:
2012-04-06  Jiri Vanek <jvanek at redhat.com>

	Added detection of installed browsers and added targets to create symbolic links from install dir
to browsers' plugin directories. Primarily for testing purposes
	*Makefile.am: (clean-local) optionally delets links' stamps
	(stamps/user-links.stamp) with alias (links) - new target for creating symlinks for all users. One
must be root to execute this target.
	(stamps/global-links.stamp) with alias (user-links) - new target for creating symlinks for logged
user only. Because opera is missing this feature, quite useless.
	*configure.ac: added basic check whether and which browsers are installed

-------------- next part --------------
A non-text attachment was scrubbed...
Name: makeLinks.diff
Type: text/x-patch
Size: 5212 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120416/08a69fa8/makeLinks.diff 

From jvanek at redhat.com  Mon Apr 16 05:53:24 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Mon, 16 Apr 2012 14:53:24 +0200
Subject: RFC - Reduce loading of PropertiesFile
In-Reply-To: <1334520186.1444.43.camel@localhost.localdomain>
References: <1334087640.1431.26.camel@localhost.localdomain>	
	<4F86D475.5020202@redhat.com>
	<1334520186.1444.43.camel@localhost.localdomain>
Message-ID: <4F8C1644.5090001@redhat.com>

On 04/15/2012 10:03 PM, Thomas Meyer wrote:
> Am Donnerstag, den 12.04.2012, 15:11 +0200 schrieb Jiri Vanek:
>> Hi!
>
> Hey!
>
>> diffs as attachments and changelogs as plaintext please :)
>
> oops! Yes, sorry. Here you go:
>
> 2012-04-15  Thomas Meyer<thomas at m3y3r.de>
>
> 	* netx/net/sourceforge/jnlp/util/PropertiesFile.java
> 	Reduce no. of disk accesses in (load) when the recently_used file was not
> 	changed since the last (store).
> 	* netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java: (load)
> 	Avoid call of (checkData), when file was not changed.
>
> New patch(es) against tip as attachment.
>
>>
>> Idea looks excelent, but several issues inline:
>>
>> On 04/10/2012 09:54 PM, Thomas Meyer wrote:
>>> diff -r 60ef5191add3 netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java
>>> --- a/netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java	Tue Apr 10 19:10:43 2012 +0200
>>> +++ b/netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java	Tue Apr 10 21:49:08 2012 +0200
>>> @@ -108,11 +108,11 @@
>>>         * Update map for keeping track of recently used items.
>>>         */
>>>        public synchronized void load() {
>>> -        cacheOrder.load();
>>> +        boolean loaded = cacheOrder.load();
>>>            /*
>>>             * clean up possibly corrupted entries
>>>             */
>>> -        if (checkData()) {
>>> +        if (loaded == true&&   checkData()) {
>> +        if (loaded&&  checkData()) {
>> please ;)
>> (unless it somehow destroy difference between&&  and&  O:) )
>
> &&  is the right thing to do here! we want to avoid the call of
> checkData(), when the file was not reloaded.
>
argh. I wrote it really wrong :)
My "correction" was directed to loaded == true not to &&.
So what I would like to see is (loaded &&  checkData()) if nothing serious against.
Sorry for miss-formulating.
>>
>>>                if (JNLPRuntime.isDebug()) {
>>>                    new LruCacheException().printStackTrace();
>>>                }
>>> @@ -125,7 +125,7 @@
>>>        /**
>>>         * check content of cacheOrder and remove invalid/corrupt entries
>>>         *
>>> -     * @return true, if cache was coruupted and affected entry removed
>>> +     * @return true, if cache was corrupted and affected entry removed
>>>         */
>>>        private boolean checkData () {
>>>            boolean modified = false;
>>> diff -r 60ef5191add3 netx/net/sourceforge/jnlp/util/PropertiesFile.java
>>> --- a/netx/net/sourceforge/jnlp/util/PropertiesFile.java	Tue Apr 10 19:10:43 2012 +0200
>>> +++ b/netx/net/sourceforge/jnlp/util/PropertiesFile.java	Tue Apr 10 21:49:08 2012 +0200
>>> @@ -35,6 +35,9 @@
>>>
>>>        /** the header string */
>>>        String header = "netx file";
>>> +
>>> +    /** time of last modification */
>>> +    long lastStore;
>>>
>>>        /** lazy loaded on getProperty */
>>>        boolean loaded = false;
>>> @@ -104,24 +107,32 @@
>>>         * Ensures that the file backing these properties has been
>>>         * loaded; call this method before calling any method defined by
>>>         * a superclass.
>>> +     *
>>> +     * @return true, if file was (re-)loaded
>>> +     *         false, if file was still current
>>>         */
>>> -    public void load() {
>>> +    public boolean load() {
>>>            loaded = true;
>> Looks like unused?
>
> No. This is an already present optimisation to lazy load the file on the
> first call of getProperty().
Still looks  strange but ok for me for now.
>
>>>
>>> -        InputStream s = null;
>>> -        try {
>> this
>>> -            if (!file.exists())
>>> -                return;
>> should remains here, returning false, as you are testing file.lastModified() later
> okay.
>
>>
>>> +        if(lastStore == 0 || lastStore>   0&&   file.lastModified() != lastStore) {
>> I believe this lastStore>   0 is redudat:
>> if(lastStore == 0 || file.lastModified() != lastStore)
>> will do the same thing?
>
> lastModified() tells:
> "returns [...] 0L if the file does not exist or if an I/O error occurs"
>
> lastStore will be zero as it is initialised at object creation time.
>
> so I wanted to make sure to at least try to load the file once.
> does that makes sense?

fair enough. In your new patch you have fileexists before this statement anyway.
>
>>
>>> +            InputStream s = null;
>>> +            try {
>> this
>>> +                if (!file.exists())
>>> +                    return false;
>> will be redundant then (^^^)
>
> okay.
>
>>> +
>>> +                try {
>>> +                    s = new FileInputStream(file);
>> When you are touching this, I believe the encoding of this file should be during storing and loading
>> namely specified as utf-8 (icedtea-web have issues with encodings... so its better to start sooner
>> then later)
>
> FileInputStream is a byte stream, so no character set is interpreted
> here. also the class PropertiesFile is an subclass of Properties.
>
Sorry! My overlook! I'm quite paranoid about new FileReader() which is using platform dependent default encoding, which I consider as one of the fundamental errors in java. (and it is hurting icedtea-web imho when dealing with jnlps in different encoding then utf-8, which windows users are still using )
And I have miss-read FileInputStream. :-/

> Properties.load() tells:
>
> "Reads a property list (key and element pairs) from the input byte
> stream. The input stream is in a simple line-oriented format as
> specified in load(Reader) and is assumed to use the ISO 8859-1 character
omg.. But never mind.. Definitely behind scope of this patch:)
> encoding; that is each byte is one Latin1 character. Characters not in
> Latin1, and certain special characters, are represented in keys and
> elements using Unicode escapes."
>
> so I think we should not use a different character set here.
>
>>> +                    load(s);
>>         *1 (see below ;)
>>> +                } finally {
>>> +                    if (s != null) s.close();
>>> +                }
>>> +            } catch (IOException ex) {
>>> +                ex.printStackTrace();
>> return false here?
>
> yes, of course. fixed.
>
>>> +            }
>>> +            return true;
>> no return here here
>>> +        }
>>>
>>> -            try {
>>> -                s = new FileInputStream(file);
>>> -                load(s);
>>> -            } finally {
>>> -                if (s != null) s.close();
>>> -            }
>>> -        } catch (IOException ex) {
>>> -            ex.printStackTrace();
>>> -        }
>>> +        return false;
>> shouldn't  there be return true/nothing (returns already solved) - considering my hints are valid?
>>>        }
>>>
>>>        /**
>>> @@ -137,6 +148,7 @@
>>>                    file.getParentFile().mkdirs();
>>>                    s = new FileOutputStream(file);
>>>                    store(s, header);
>>> +                lastStore = file.lastModified();
>> This is shouldn't be there. I would like to move lastStore = file.lastModified(); to load function.
>
> fixed.
>
>> or  to "*1" location (because reason of this timestamp is also external modification of recently_used)
>>>                } finally {
>>>                    if (s != null) s.close();
>>>                }
>>>
>>>
>> Little bit of-the-basin think - are you sure that store() as it is written changes lastModified()
>> linux stamp correctly? (I had some bad experiences with this, but have never examined it separately)
>
> no. a fsync() was missing here. fixed.
>
>>
>> Also I would like to suggest at least two tests with this patch
>> 1) generate eg 1mb recently_used file and measure set some deadline how fast javaws  have to start.
>>     The value should be failing without this patch, and  passing with this one applied. Also some
>> real number how faster this is will be much appreciate!
>>
>> 2) second one will be little bit more difficult. It would be nice to test, that when recently_used
>> is modified during javaws run, then it reloads it correctly. And so verify that this patch will not
>> cause some regression.
>>
>>
>> Maybe unittest will be easier to prepare instead of 2)
>> But I'm afraid those (or similar ) tests will be really necessary.
>
> I'll write some test cases and will get some figures.
Thank you very much in advice.
>
>> What do you think?
>
> sounds good to me.
>
>>
Patch looks ok now (except several nitpickcs inline)  but I would like to wait with pushing until tests are done.

>> btw - there is task[1] which have long-term goal to rewrite cache subsystem. Do you want to be
>> volunteer?
>
> Sorry, but I can only do some small contributions, as this is just a
> hobby for me. This sounds more like a full-time job...

And so am I :) But I wanted to make my shot O:)
>
> with kind regards
> thomas
>

 >


 > diff -r 17f9e4e1ac6d netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java
--- a/netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java	Wed Apr 11 10:19:17 2012 +0200
+++ b/netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java	Mon Apr 16 14:08:18 2012 +0200
@@ -108,11 +108,11 @@
       * Update map for keeping track of recently used items.
       */
      public synchronized void load() {
-        cacheOrder.load();
+        boolean loaded = cacheOrder.load();
          /*
           * clean up possibly corrupted entries
           */
-        if (checkData()) {
+        if (loaded == true && checkData()) {

 > As already told above, Unless there is some particular reason, please avoid boolean comparsion with true/false

              if (JNLPRuntime.isDebug()) {
                  new LruCacheException().printStackTrace();
              }
@@ -125,7 +125,7 @@
      /**
       * check content of cacheOrder and remove invalid/corrupt entries
       *
-     * @return true, if cache was coruupted and affected entry removed
+     * @return true, if cache was corrupted and affected entry removed
       */
      private boolean checkData () {
          boolean modified = false;
diff -r 17f9e4e1ac6d netx/net/sourceforge/jnlp/util/PropertiesFile.java
--- a/netx/net/sourceforge/jnlp/util/PropertiesFile.java	Wed Apr 11 10:19:17 2012 +0200
+++ b/netx/net/sourceforge/jnlp/util/PropertiesFile.java	Mon Apr 16 14:08:18 2012 +0200
@@ -35,6 +35,9 @@

      /** the header string */
      String header = "netx file";
+
+    /** time of last modification */
+    long lastStore;

      /** lazy loaded on getProperty */
      boolean loaded = false;
@@ -104,24 +107,38 @@
       * Ensures that the file backing these properties has been
       * loaded; call this method before calling any method defined by
       * a superclass.
+     *
+     * @return true, if file was (re-)loaded
+     *         false, if file was still current
       */
-    public void load() {
+    public boolean load() {
+
+        if (!file.exists())
+            return false;

 > this is really nitpick and I'm sorry for it, but current code guidelines dictate brackets after if
 > +        if (!file.exists()) {
 > +            return false;
 > +            }
 > +
          loaded = true;

-        InputStream s = null;
-        try {
-            if (!file.exists())
-                return;
+        long currentStore = file.lastModified();
+        if(lastStore == 0 || currentStore != lastStore) {
+            InputStream s = null;
+            try {

-            try {
-                s = new FileInputStream(file);
-                load(s);
-            } finally {
-                if (s != null) s.close();
+                try {
+                    s = new FileInputStream(file);
+                    load(s);
+                } finally {
+                    if (s != null) {
+                        s.close();
+                        lastStore=currentStore;
+                        return true;
+                    }
+                }
+            } catch (IOException ex) {
+                ex.printStackTrace();
              }
-        } catch (IOException ex) {
-            ex.printStackTrace();
          }
+
+        return false;
      }

      /**
@@ -131,12 +148,16 @@
          if (!loaded)
              return; // nothing could have changed so save unnecessary load/save

-        OutputStream s = null;
+        FileOutputStream s = null;
          try {
              try {
                  file.getParentFile().mkdirs();
                  s = new FileOutputStream(file);
                  store(s, header);
+
+                // fsync()
+                s.getChannel().force(true);
+                lastStore = file.lastModified();
 > Very well :) I have never seen this before, so I hope you know what you are doing:) (but looks correct from javadoc)
              } finally {
                  if (s != null) s.close();
              }

Best regards, thanx for patch and looking forward to tests!

J.


From fcassia at gmail.com  Mon Apr 16 05:57:27 2012
From: fcassia at gmail.com (Fernando Cassia)
Date: Mon, 16 Apr 2012 09:57:27 -0300
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream, its
	name should be openjdk-plugin !
In-Reply-To: <1334574325.2986.9.camel@springer.wildebeest.org>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>
	<20120416073159.GB21928@toonder.wildebeest.org>
	<CACGw4H4Y-=pr96X3-8hu8Zr5bkc99SPpdbY69mZ1ih4TEwF_dA@mail.gmail.com>
	<1334574325.2986.9.camel@springer.wildebeest.org>
Message-ID: <CACGw4H6rS5R4fvAP6tBZp-Bwui25utkAik7RQ3Fqt-ROp+wRBw@mail.gmail.com>

On Mon, Apr 16, 2012 at 08:05, Mark Wielaard <mark at klomp.org> wrote:

> Mark Reinhold contributed a patch some time ago to IcedTea to make it
> comply with that trademark license and only call it OpenJDK if it was
> configured "in the right way", which has been integrated.
> http://thread.gmane.org/gmane.comp.java.openjdk.distro-packaging.devel/4863
>
> Cheers,
>



-- 
During times of Universal Deceit, telling the truth becomes a revolutionary
act
Durante ?pocas de Enga?o Universal, decir la verdad se convierte en un Acto
Revolucionario
- George Orwell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120416/575ee964/attachment.html 

From ahughes at redhat.com  Mon Apr 16 06:59:00 2012
From: ahughes at redhat.com (Andrew Hughes)
Date: Mon, 16 Apr 2012 09:59:00 -0400 (EDT)
Subject: porting icedtea6 to FreeBSD
In-Reply-To: <CAMuy=+hj4r2L3N137q+5B4qdDvJQDbvrtAUDU2yWS7xK12kYHg@mail.gmail.com>
Message-ID: <58ebb855-f324-4058-b29c-1b1b5901108f@zmail17.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> 
> 
> 
> On Thu, Mar 29, 2012 at 5:04 PM, Jason Helfman < jgh at freebsd.org >
> wrote:
> 
> 
> On Thu, Mar 29, 2012 at 06:49:25PM -0400, Andrew Hughes thus spake:
> 
> 
> 
> I don't know what's available on FreeBSD. We've tended to use gcj to
> get
> off the starting blocks, but OpenJDK6 works too.
> 
> I'll try openjdk6 first, and then if I can get it to work try others.
> 
> 
> 
> 
> 
> What makes you say I am not using the latest? I did update to 1.11.1
> for
> this latest build.
> https://redports.org/browser/ jgh/java/icedtea6/Makefile
> 
> Ok I didn't see that. Sorry.
> As I say, you may still find hg useful for contributing back.
> 
> Ok, I'll keep this in mind.
> 
> 
> 
> 
> 
> 
> Yes, I noticed this with the change to 1.11.1, and removed those from
> my
> Makefile.
> 
> Good.
> 
> 
> 
> >> 
> >> This has been resolved with later releases, and the patching is
> >> probably a
> >> result of misconfigured configured options.
> > 
> >I doubt it from what I've seen of what you're doing.
> > 
> >The issue seems to be that your OpenJDK sources are not in the
> >expected state.
> 
> It is the same checksum, though, and the same location that is
> fetched
> during the icedtea build. I just pre-fetch them, and assign it as a
> configure option.
> Here is a link to the files with the checksums that are used:
> https://redports.org/browser/ jgh/java/icedtea6/distinfo
> 
> 
> Can you provide a log of what happens when you run make? Something
> is clearly going wrong, but I can't see what if the tarballs are ok.
> Are you starting from a clean directory?
> 
> I am starting from a clean directory every time I build.
> Attached is the log you've requested.
> 
> Thanks!
> 
> 
> 
> Any thoughts on any of this?
> Thanks, again.
> 
> -jgh
> 
> 

What are you doing here?

/usr/bin/sed -i.bak -e 's|--dry-run||g' /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.am /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.in
/usr/bin/sed -i.bak -e 's|--check|-q|g' /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.am /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.in

If you're removing --dry-run, you're going to be applying the patch twice, which is why it's failing.
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From ddadacha at redhat.com  Mon Apr 16 09:15:58 2012
From: ddadacha at redhat.com (Danesh Dadachanji)
Date: Mon, 16 Apr 2012 12:15:58 -0400
Subject: [RFC][icedtea-web] Fix for PR855: AppletStub getDocumentBase()
	doesn't return full URL
In-Reply-To: <4F2C425B.2040805@redhat.com>
References: <4F2C425B.2040805@redhat.com>
Message-ID: <4F8C45BE.6090207@redhat.com>

On 03/02/12 03:23 PM, Danesh Dadachanji wrote:
> Hi,
>
> This patch is a fix for PR855[1]. The return of getDocumentBase() currently doesn't include the HTML file. According to the docs, it
> should return the entire path of the HTML, including the filename.
>
> Attached is a patch that adds this. I've checked all the traces of the bytes grabbed from the pipe over on the java side. I believe I
> covered every read and assignment of the buffer/vars setup from the buffer and so on. We fortunately only ever used getDocumentBase()'s
> return to grab the host IP or use it as a base URL. The latter code grabbed the return and cut off everything after the last '/', which
> back before patch is the entire URL, post patch is the URL excluding the file name.
>
> Okay for HEAD? Thoughts on backporting to release branches? It was reported against 1.1.3 but this is a pretty big change that
> potentially affects the way users' applications behave.
>
> +2012-02-03 Danesh Dadachanji <ddadacha at redhat.com>
> +
> + PR855: AppletStub getDocumentBase() doesn't return full URL
> + * plugin/icedteanp/IcedTeaNPPlugin.cc (plugin_get_documentbase): Fixed
> + location string storing the document base to include the HTML file.
> +
>
> Regards,
> Danesh
>
> [1] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=855

Ping?


From adinn at icedtea.classpath.org  Mon Apr 16 08:50:56 2012
From: adinn at icedtea.classpath.org (adinn at icedtea.classpath.org)
Date: Mon, 16 Apr 2012 15:50:56 +0000
Subject: /hg/release/icedtea7-forest-2.1/jdk: 7150392: Linux build breaks...
Message-ID: <hg.7ceda3124828.1334591456.7272495575031205070@icedtea.classpath.org>

changeset 7ceda3124828 in /hg/release/icedtea7-forest-2.1/jdk
details: http://icedtea.classpath.org/hg/release/icedtea7-forest-2.1/jdk?cmd=changeset;node=7ceda3124828
author: andrew
date: Wed Apr 11 14:58:50 2012 +0100

	7150392: Linux build breaks with GCC 4.7 due to unrecognized option
	Summary: Remove -mimpure-text option.
	Reviewed-by: ohair, dholmes, phh, andrew
	Contributed-by: Deepak Bhole <dbhole at redhat.com>


diffstat:

 make/common/shared/Compiler-gcc.gmk                         |  2 +-
 src/share/demo/jvmti/compiledMethodLoad/sample.makefile.txt |  2 +-
 src/share/demo/jvmti/gctest/sample.makefile.txt             |  2 +-
 src/share/demo/jvmti/heapTracker/sample.makefile.txt        |  2 +-
 src/share/demo/jvmti/heapViewer/sample.makefile.txt         |  2 +-
 src/share/demo/jvmti/hprof/sample.makefile.txt              |  2 +-
 src/share/demo/jvmti/index.html                             |  6 +++---
 src/share/demo/jvmti/java_crw_demo/sample.makefile.txt      |  2 +-
 src/share/demo/jvmti/minst/sample.makefile.txt              |  2 +-
 src/share/demo/jvmti/mtrace/sample.makefile.txt             |  2 +-
 src/share/demo/jvmti/versionCheck/sample.makefile.txt       |  2 +-
 11 files changed, 13 insertions(+), 13 deletions(-)

diffs (150 lines):

diff -r 2d8ad70a2243 -r 7ceda3124828 make/common/shared/Compiler-gcc.gmk
--- a/make/common/shared/Compiler-gcc.gmk	Fri Mar 02 10:18:25 2012 -0500
+++ b/make/common/shared/Compiler-gcc.gmk	Wed Apr 11 14:58:50 2012 +0100
@@ -133,7 +133,7 @@
     REQUIRED_GCC_VER = 4.0.*
   endif
   # Option used to create a shared library
-  SHARED_LIBRARY_FLAG = -shared -mimpure-text
+  SHARED_LIBRARY_FLAG = -shared
   SUN_COMP_VER := $(shell $(CC) --verbose 2>&1 )
 
 endif
diff -r 2d8ad70a2243 -r 7ceda3124828 src/share/demo/jvmti/compiledMethodLoad/sample.makefile.txt
--- a/src/share/demo/jvmti/compiledMethodLoad/sample.makefile.txt	Fri Mar 02 10:18:25 2012 -0500
+++ b/src/share/demo/jvmti/compiledMethodLoad/sample.makefile.txt	Wed Apr 11 14:58:50 2012 +0100
@@ -90,7 +90,7 @@
     OBJECTS=$(SOURCES:%.c=%.o)
     # Library name and options needed to build it
     LIBRARY=lib$(LIBNAME).so
-    LDFLAGS=-Wl,-soname=$(LIBRARY) -static-libgcc -mimpure-text
+    LDFLAGS=-Wl,-soname=$(LIBRARY) -static-libgcc
     # Libraries we are dependent on
     LIBRARIES=-lc
     # Building a shared library
diff -r 2d8ad70a2243 -r 7ceda3124828 src/share/demo/jvmti/gctest/sample.makefile.txt
--- a/src/share/demo/jvmti/gctest/sample.makefile.txt	Fri Mar 02 10:18:25 2012 -0500
+++ b/src/share/demo/jvmti/gctest/sample.makefile.txt	Wed Apr 11 14:58:50 2012 +0100
@@ -90,7 +90,7 @@
     OBJECTS=$(SOURCES:%.c=%.o)
     # Library name and options needed to build it
     LIBRARY=../lib/lib$(LIBNAME).so
-    LDFLAGS=-Wl,-soname=$(LIBRARY) -static-libgcc -mimpure-text
+    LDFLAGS=-Wl,-soname=$(LIBRARY) -static-libgcc
     # Libraries we are dependent on
     LIBRARIES=-lc
     # Building a shared library
diff -r 2d8ad70a2243 -r 7ceda3124828 src/share/demo/jvmti/heapTracker/sample.makefile.txt
--- a/src/share/demo/jvmti/heapTracker/sample.makefile.txt	Fri Mar 02 10:18:25 2012 -0500
+++ b/src/share/demo/jvmti/heapTracker/sample.makefile.txt	Wed Apr 11 14:58:50 2012 +0100
@@ -96,7 +96,7 @@
     OBJECTS=$(SOURCES:%.c=%.o)
     # Library name and options needed to build it
     LIBRARY=../lib/lib$(LIBNAME).so
-    LDFLAGS=-Wl,-soname=$(LIBRARY) -static-libgcc -mimpure-text
+    LDFLAGS=-Wl,-soname=$(LIBRARY) -static-libgcc
     # Libraries we are dependent on
     LIBRARIES=-L../../java_crw_demo/src/ -ljava_crw_demo -lc
     # Building a shared library
diff -r 2d8ad70a2243 -r 7ceda3124828 src/share/demo/jvmti/heapViewer/sample.makefile.txt
--- a/src/share/demo/jvmti/heapViewer/sample.makefile.txt	Fri Mar 02 10:18:25 2012 -0500
+++ b/src/share/demo/jvmti/heapViewer/sample.makefile.txt	Wed Apr 11 14:58:50 2012 +0100
@@ -90,7 +90,7 @@
     OBJECTS=$(SOURCES:%.c=%.o)
     # Library name and options needed to build it
     LIBRARY=../lib/lib$(LIBNAME).so
-    LDFLAGS=-Wl,-soname=$(LIBRARY) -static-libgcc -mimpure-text
+    LDFLAGS=-Wl,-soname=$(LIBRARY) -static-libgcc
     # Libraries we are dependent on
     LIBRARIES=-lc
     # Building a shared library
diff -r 2d8ad70a2243 -r 7ceda3124828 src/share/demo/jvmti/hprof/sample.makefile.txt
--- a/src/share/demo/jvmti/hprof/sample.makefile.txt	Fri Mar 02 10:18:25 2012 -0500
+++ b/src/share/demo/jvmti/hprof/sample.makefile.txt	Wed Apr 11 14:58:50 2012 +0100
@@ -130,7 +130,7 @@
     OBJECTS=$(SOURCES:%.c=%.o)
     # Library name and options needed to build it
     LIBRARY=lib$(LIBNAME).so
-    LDFLAGS=-Wl,-soname=$(LIBRARY) -static-libgcc -mimpure-text
+    LDFLAGS=-Wl,-soname=$(LIBRARY) -static-libgcc
     # Libraries we are dependent on
     LIBRARIES= -ldl -lc
     # Building a shared library
diff -r 2d8ad70a2243 -r 7ceda3124828 src/share/demo/jvmti/index.html
--- a/src/share/demo/jvmti/index.html	Fri Mar 02 10:18:25 2012 -0500
+++ b/src/share/demo/jvmti/index.html	Wed Apr 11 14:58:50 2012 +0100
@@ -308,7 +308,7 @@
 <code><ul>
 gcc -O2 -fPIC -pthread -DLINUX -c <i>*.c</i>
 <br>
-gcc -z defs -static-libgcc -shared -mimpure-text -o <i>libXXX.so *.o</i> -lc
+gcc -z defs -static-libgcc -shared -o <i>libXXX.so *.o</i> -lc
 </code></ul>
 <br>
 For AMD64:
@@ -316,7 +316,7 @@
 <code><ul>
 gcc -O2 -fPIC -pthread -DLINUX -D_LP64=1 -c <i>*.c</i>
 <br>
-gcc -z defs -static-libgcc -shared -mimpure-text -o <i>libXXX.so *.o</i> -lc
+gcc -z defs -static-libgcc -shared -o <i>libXXX.so *.o</i> -lc
 </code></ul>
 <br>
 </li>
@@ -339,7 +339,7 @@
 </li>
 
 <li>
-Library: Use -static-libgcc -mimpure-text.
+Library: Use -static-libgcc.
 <br>
 When building the shared library (-shared option), this option
 allows for maximum portability of the library between different
diff -r 2d8ad70a2243 -r 7ceda3124828 src/share/demo/jvmti/java_crw_demo/sample.makefile.txt
--- a/src/share/demo/jvmti/java_crw_demo/sample.makefile.txt	Fri Mar 02 10:18:25 2012 -0500
+++ b/src/share/demo/jvmti/java_crw_demo/sample.makefile.txt	Wed Apr 11 14:58:50 2012 +0100
@@ -90,7 +90,7 @@
     OBJECTS=$(SOURCES:%.c=%.o)
     # Library name and options needed to build it
     LIBRARY=lib$(LIBNAME).so
-    LDFLAGS=-Wl,-soname=$(LIBRARY) -static-libgcc -mimpure-text
+    LDFLAGS=-Wl,-soname=$(LIBRARY) -static-libgcc
     # Libraries we are dependent on
     LIBRARIES=-lc
     # Building a shared library
diff -r 2d8ad70a2243 -r 7ceda3124828 src/share/demo/jvmti/minst/sample.makefile.txt
--- a/src/share/demo/jvmti/minst/sample.makefile.txt	Fri Mar 02 10:18:25 2012 -0500
+++ b/src/share/demo/jvmti/minst/sample.makefile.txt	Wed Apr 11 14:58:50 2012 +0100
@@ -96,7 +96,7 @@
     OBJECTS=$(SOURCES:%.c=%.o)
     # Library name and options needed to build it
     LIBRARY=../lib/lib$(LIBNAME).so
-    LDFLAGS=-Wl,-soname=$(LIBRARY) -static-libgcc -mimpure-text
+    LDFLAGS=-Wl,-soname=$(LIBRARY) -static-libgcc
     # Libraries we are dependent on
     LIBRARIES=-L../../java_crw_demo/src/ -ljava_crw_demo -lc
     # Building a shared library
diff -r 2d8ad70a2243 -r 7ceda3124828 src/share/demo/jvmti/mtrace/sample.makefile.txt
--- a/src/share/demo/jvmti/mtrace/sample.makefile.txt	Fri Mar 02 10:18:25 2012 -0500
+++ b/src/share/demo/jvmti/mtrace/sample.makefile.txt	Wed Apr 11 14:58:50 2012 +0100
@@ -96,7 +96,7 @@
     OBJECTS=$(SOURCES:%.c=%.o)
     # Library name and options needed to build it
     LIBRARY=../lib/lib$(LIBNAME).so
-    LDFLAGS=-Wl,-soname=$(LIBRARY) -static-libgcc -mimpure-text
+    LDFLAGS=-Wl,-soname=$(LIBRARY) -static-libgcc
     # Libraries we are dependent on
     LIBRARIES=-L../../java_crw_demo/src -ljava_crw_demo -lc
 
diff -r 2d8ad70a2243 -r 7ceda3124828 src/share/demo/jvmti/versionCheck/sample.makefile.txt
--- a/src/share/demo/jvmti/versionCheck/sample.makefile.txt	Fri Mar 02 10:18:25 2012 -0500
+++ b/src/share/demo/jvmti/versionCheck/sample.makefile.txt	Wed Apr 11 14:58:50 2012 +0100
@@ -90,7 +90,7 @@
     OBJECTS=$(SOURCES:%.c=%.o)
     # Library name and options needed to build it
     LIBRARY=../lib/lib$(LIBNAME).so
-    LDFLAGS=-Wl,-soname=$(LIBRARY) -static-libgcc -mimpure-text
+    LDFLAGS=-Wl,-soname=$(LIBRARY) -static-libgcc
     # Libraries we are dependent on
     LIBRARIES=-lc
     # Building a shared library


From dbhole at redhat.com  Mon Apr 16 10:18:16 2012
From: dbhole at redhat.com (Deepak Bhole)
Date: Mon, 16 Apr 2012 13:18:16 -0400
Subject: [RFC][icedtea-web] Fix for PR855: AppletStub getDocumentBase()
	doesn't return full URL
In-Reply-To: <4F2C425B.2040805@redhat.com>
References: <4F2C425B.2040805@redhat.com>
Message-ID: <20120416171814.GB14177@redhat.com>

* Danesh Dadachanji <ddadacha at redhat.com> [2012-02-03 15:40]:
> Hi,
> 
> This patch is a fix for PR855[1]. The return of getDocumentBase()
> currently doesn't include the HTML file. According to the docs, it
> should return the entire path of the HTML, including the filename.
> 
> Attached is a patch that adds this. I've checked all the traces of
> the bytes grabbed from the pipe over on the java side. I believe I
> covered every read and assignment of the buffer/vars setup from the
> buffer and so on. We fortunately only ever used getDocumentBase()'s
> return to grab the host IP or use it as a base URL. The latter code
> grabbed the return and cut off everything after the last '/', which
> back before patch is the entire URL, post patch is the URL excluding
> the file name.
> 
> Okay for HEAD? Thoughts on backporting to release branches? It was
> reported against 1.1.3 but this is a pretty big change that
> potentially affects the way users' applications behave.
> 

Looking at the surrounding code, we are taking a URL, splitting it on
"/" and then combining the first length-1 components. This was done to
purposely remove the file name itself.

However if we want to add the file name back, we should just remove all
of the splitting/combing code rather than appending the last part.

Have you tried using NPVARIANT_TO_STRING(href).utf8characters directly?

Cheers,
Deepak

> +2012-02-03  Danesh Dadachanji  <ddadacha at redhat.com>
> +
> +	PR855: AppletStub getDocumentBase() doesn't return full URL
> +	* plugin/icedteanp/IcedTeaNPPlugin.cc (plugin_get_documentbase): Fixed
> +	location string storing the document base to include the HTML file.
> +
> 
> Regards,
> Danesh
> 
> [1] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=855

> diff --git a/plugin/icedteanp/IcedTeaNPPlugin.cc b/plugin/icedteanp/IcedTeaNPPlugin.cc
> --- a/plugin/icedteanp/IcedTeaNPPlugin.cc
> +++ b/plugin/icedteanp/IcedTeaNPPlugin.cc
> @@ -1094,6 +1094,7 @@ plugin_get_documentbase (NPP instance)
>        location_str += "/";
>    }
>  
> +  location_str += parts[parts_sz - 1]; // Need to add the html file name.
>    documentbase_copy = g_strdup (location_str.c_str());
>  
>    // Release references.



From ddadacha at redhat.com  Mon Apr 16 13:32:07 2012
From: ddadacha at redhat.com (Danesh Dadachanji)
Date: Mon, 16 Apr 2012 16:32:07 -0400
Subject: [RFC][icedtea-web] Unit tests for the new updates to JarSIgner
	(incomplete)
In-Reply-To: <4F821CDE.9090101@redhat.com>
References: <4F7A1037.7060405@redhat.com> <4F7CDAF7.6090503@redhat.com>
	<4F7F66C2.8060506@redhat.com> <4F821CDE.9090101@redhat.com>
Message-ID: <4F8C81C7.6030501@redhat.com>

On 08/04/12 07:18 PM, Omair Majid wrote:
> On 04/06/2012 05:57 PM, Danesh Dadachanji wrote:

[snip]

>> I've attached a new patch that loosens up the code a bit, I've padded
>> newlines above (and below) the chunk of asserts. There are a few more
>> modifications as follows.
>>
>> 1) The new patch also brings in the changeset that renames JarSigner to
>> JarCertVerifier[1] so hopefully it won't throw reviewers off too much.
>
> Great :)
>
>> 2) In the tests that run 1 entry than 3 entries, I've reset
>> JarCertVerifier to a new instance when the three-entry vector is used. I
>> think this may cause confusion later on because there would have been
>> cases where the JarCertVerifier would have totalSignableEntries = 4
>> instead of 3.
>
> Hm... If you are doing this, I would recommend you go all the way and
> split the 1-entry/3-entry tests into different methods to isolate the
> tests completely.
>

Done! It looks a little bit more heavy and jumps up to 22 unit tests. All in all though, I think it looks good.

>> 3) Lastly, I've added a new set of asserts using the following two methods:
>>
>>      /**
>>       * Checks if the provided cert path has signed any of the jars
>> associated
>>       * with the cert verifier.
>>       * @param certPath The cert path of the potential signer.
>>       * @return Whether or not the cert path represents one of the
>> signers of
>>       * a jar associated with the verifier.
>>       */
>>      boolean hasJarSigner(CertPath certPath)
>
> The name is not very descriptive. How about something like
> certHasSignedAnyJar? Also, why a certPath instead of a cert?
>

Yeah, not too sure what I was thinking when I came up with the name. Please see the comment below.

>>      /**
>>       * Calculate the number of signers all the jars have in total.
>>       *
>>       * Note this is not the number of common signers across all jars. It is
>>       * the number of common signers each jar has with respect to itself,
>>       * totalled together across the other jars.
>>       * @return The number of signers that have signed at least one jar
>> entirely.
>>       */
>>      int numSigners()
>>
>
> Likewise, this name doesn't convey much. I am still trying to figure out
> what this method does.
>
> Are these methods public? Any reason why we are adding these (or are
> they just for tests)gf?

Yes, these methods are just for tests)gf only. ;)

I have rethought these 2 methods and decided not to use them. What they did was essentially grab the key set of the hash map that 
managed all the signers, then check if the list contains the CertPath or return the size of the list. Instead of creating extra methods 
for duplicate info, I'm just going to use JarCertVerifier.getCerts() in the tests.

Here's a little background info on the key set. If the CertPath is a key of the hash map, that means that this CertPath has signed at 
least one jar entirely (namely, every signable entry has been signed). So if the tests run as expected, the end result is one of the 
signers being set as the key (if expected). The size is also checked to make sure nothing else slipped in by mistake. I've changed the 
asserts to use this instead. I hope this is more clear!

Main differences in this patch:
   1) Separate single-entry and many-entry tests into their own methods
   2) Rework calls to numSigners and hasJarSigner to use jcv.getCerts()'s .contains(signer) and .size()

Thanks for the review!

Cheers,
Danesh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jar-signer-tests-03.patch
Type: text/x-patch
Size: 33813 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120416/6273e333/jar-signer-tests-03.patch 

From jgh at FreeBSD.org  Mon Apr 16 23:40:43 2012
From: jgh at FreeBSD.org (Jason Helfman)
Date: Mon, 16 Apr 2012 23:40:43 -0700
Subject: porting icedtea6 to FreeBSD
In-Reply-To: <58ebb855-f324-4058-b29c-1b1b5901108f@zmail17.collab.prod.int.phx2.redhat.com>
References: <CAMuy=+hj4r2L3N137q+5B4qdDvJQDbvrtAUDU2yWS7xK12kYHg@mail.gmail.com>
	<58ebb855-f324-4058-b29c-1b1b5901108f@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <20120417064043.GA17160@dormouse.experts-exchange.com>

On Mon, Apr 16, 2012 at 09:59:00AM -0400, Andrew Hughes thus spake:
>> Any thoughts on any of this?
>> Thanks, again.
>>
>> -jgh
>
>What are you doing here?
>
>/usr/bin/sed -i.bak -e 's|--dry-run||g' /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.am /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.in
>/usr/bin/sed -i.bak -e 's|--check|-q|g' /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.am /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.in
>
>If you're removing --dry-run, you're going to be applying the patch twice, which is why it's failing.
>-- 
>Andrew :)

I've modified this to test the patch which in FreeBSD is the "-C" switch,
and the "-q" is for SHASUM's to only output the hash.

I was able to get much further in the build! Any thoughts on why this patch
was seen as already applied?

-jgh

-- 
Jason Helfman         | FreeBSD Committer
jgh at FreeBSD.org       | http://people.freebsd.org/~jgh
-------------- next part --------------
===>  License check disabled, port has not defined LICENSE
===>  Extracting for icedtea6-1.11.1
=> SHA256 Checksum OK for icedtea6-1.11.1.tar.gz.
=> SHA256 Checksum OK for jaxp144_03.zip.
=> SHA256 Checksum OK for jdk6-jaxws2_1_6-2011_06_13.zip.
=> SHA256 Checksum OK for jdk6-jaf-b20.zip.
=> SHA256 Checksum OK for openjdk-6-src-b24-14_nov_2011.tar.gz.
===>  Patching for icedtea6-1.11.1
/usr/bin/sed -i.bak -e 's|--dry-run|-C|g' /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.am /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.in
/usr/bin/sed -i.bak -e 's|--check|-q|g' /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.am /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.in
===>   icedtea6-1.11.1 depends on executable: gcj46 - found
===>   icedtea6-1.11.1 depends on package: eclipse-ecj>=3.7.2 - found
===>   icedtea6-1.11.1 depends on package: xalan-j>=2.7.1 - found
===>   icedtea6-1.11.1 depends on package: rhino>=1.7.r3 - found
===>   icedtea6-1.11.1 depends on package: cups-client>=1.5.2 - found
===>   icedtea6-1.11.1 depends on file: /usr/local/libdata/pkgconfig/mozilla-plugin.pc - found
===>   icedtea6-1.11.1 depends on executable: pkg-config - found
===>   icedtea6-1.11.1 depends on file: /usr/local/openjdk6/bin/java - found
===>   icedtea6-1.11.1 depends on file: /usr/local/bin/autoconf-2.68 - found
===>   icedtea6-1.11.1 depends on executable: pkg-config - found
===>   icedtea6-1.11.1 depends on shared library: jpeg.11 - found
===>   icedtea6-1.11.1 depends on shared library: gif.5 - found
===>   icedtea6-1.11.1 depends on shared library: esd.2 - found
===>   icedtea6-1.11.1 depends on shared library: glib-12.3 - found
===>   icedtea6-1.11.1 depends on shared library: gnome.5 - found
===>   icedtea6-1.11.1 depends on shared library: gtk-12.2 - found
===>   icedtea6-1.11.1 depends on shared library: xml.5 - found
===>   icedtea6-1.11.1 depends on shared library: Imlib.5 - found
===>   icedtea6-1.11.1 depends on shared library: ORBit.2 - found
===>  Configuring for icedtea6-1.11.1
checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking how to create a pax tar archive... gnutar
checking build system type... amd64-portbld-freebsd8.2
checking host system type... amd64-portbld-freebsd8.2
checking for gcc... cc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether cc accepts -g... yes
checking for cc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of cc... none
checking whether we are using the GNU C++ compiler... yes
checking whether c++ accepts -g... yes
checking dependency style of c++... none
checking for make... /usr/bin/make
checking for gzip... /usr/bin/gzip
checking for ant... /usr/local/bin/ant
checking for find... /usr/bin/find
checking for patch... /usr/bin/patch
checking for tar... /usr/bin/tar
checking for chmod... /bin/chmod
checking for sha256sum... /sbin/sha256
checking for wget... /usr/local/bin/wget
checking for zip... /usr/local/bin/zip
checking for unzip... /usr/local/bin/unzip
checking for cpio... /usr/bin/cpio
checking for file... /usr/bin/file
checking for fastjar... no
checking for jar... jar
checking for ldd... ldd
checking for gawk... /usr/local/bin/gawk
checking for hg... no
checking for an OpenJDK source directory... /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/openjdk
checking for lsb_release... no
checking whether to compile ecj natively... no
checking which HotSpot build to use... original
checking for linux32... no
checking version of GCC... 4.2.1 (major version 4, minor version 2)
checking for getconf... /usr/bin/getconf
checking the number of online processors... getconf: no such configuration parameter `_NPROCESSORS_ONLN'
2
checking how many parallel build jobs to execute... 2
checking if cp supports --reflink... no
checking if we can hard link rather than copy from /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1... yes
checking if a PaX-enabled kernel is running... no
checking for system library directory... 
checking for pkg-config... /usr/local/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for NSS... yes
checking whether to disable the execution of the JTReg tests... no
checking whether to disable the execution of the HotSpot JTReg tests... no
checking whether to disable the execution of the langtools JTReg tests... no
checking whether to disable the execution of the JDK JTReg tests... no
checking for xvfb-run... no
checking for an Ant home directory... /usr/share/ant
checking whether to include PulseAudio support... no
checking whether to build documentation... yes
checking whether to enable experimental OpenJDK cross-compilation support... no
checking whether to include the XRender pipeline... yes
checking whether to include SystemTap tracing support... no
checking whether to include the NSS-based security provider... disabled by default (edit java.security to enable)
checking for distribution package version... none
checking build identification... Custom build (Mon Apr 16 21:11:33 PDT 2012)
checking whether to build a bootstrap version first... yes
checking for a JDK home directory... /usr/local/jdk1.6.0
checking if a java binary was specified... no
checking if /usr/local/jdk1.6.0/bin/java is a valid executable file... yes
checking for javac... /usr/local/bin/javac
checking if a javah binary was specified... no
checking if /usr/local/jdk1.6.0/bin/javah is a valid executable file... yes
checking if a jar binary was specified... no
checking if /usr/local/jdk1.6.0/bin/jar is a valid executable file... yes
checking whether jar supports @<file> argument... yes
checking whether jar supports stdin file arguments... no
checking whether jar supports -J options at the end... yes
checking if a rmic binary was specified... no
checking if /usr/local/jdk1.6.0/bin/rmic is a valid executable file... yes
checking if a native2ascii binary was specified... no
checking if /usr/local/jdk1.6.0/bin/native2ascii is a valid executable file... yes
checking for an ecj JAR file... /usr/local/share/java/classes/ecj-3.7.2.jar
checking for xsltproc... /usr/local/bin/xsltproc
checking whether to include Javascript support via Rhino... /usr/local/share/java/rhino/rhino.jar
checking for an OpenJDK source zip... /usr/ports/distfiles/openjdk-6-src-b24-14_nov_2011.tar.gz
checking for a HotSpot source zip... not specified
checking for an alternate jar command... not specified
checking for a JAXP drop zip... /usr/ports/distfiles/jaxp144_03.zip
checking for a JAF drop zip... /usr/ports/distfiles/jdk6-jaf-b20.zip
checking for a JAXWS drop zip... /usr/ports/distfiles/jdk6-jaxws2_1_6-2011_06_13.zip
checking whether to use CACAO as VM... no
checking for a CACAO home directory... $(abs_top_builddir)/cacao/install
checking for a CACAO source zip... not specified
checking for a CACAO source directory... not specified
checking whether to use JamVM as VM... no
checking for a JamVM source zip... not specified
checking whether to disable optimizations and build with -O0 -g... no
checking whether to use the Shark JIT... no
checking how to run the C preprocessor... cpp
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether to use the zero-assembler port... yes
checking whether byte ordering is bigendian... no
checking for additional virtual machines to build... none
checking whether to retrieve the source code from Mercurial... no
checking which Mercurial revision to use... tip
checking which Java timezone data directory to use... /usr/share/javazi
checking if javax.xml.stream.events.Attribute.getDTDType() wrongly returns a QName... no
checking if /usr/local/jdk1.6.0/bin/javah exhibits Classpath bug 39408... no
checking if /usr/local/jdk1.6.0/bin/javah exhibits Classpath bug 40188... no
checking cups/cups.h usability... yes
checking cups/cups.h presence... yes
checking for cups/cups.h... yes
checking cups/ppd.h usability... yes
checking cups/ppd.h presence... yes
checking for cups/ppd.h... yes
checking X11/X.h usability... yes
checking X11/X.h presence... yes
checking for X11/X.h... yes
checking for main in -ljpeg... yes
checking for main in -lgif... yes
checking for main in -lz... yes
checking for XPROTO... yes
checking for XT... yes
checking for XP... yes
checking for X11... yes
checking for XINERAMA... yes
checking for XRENDER... yes
checking for absolute java home install dir... /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/openjdk.build/j2sdk-image
checking for LIBPNG... yes
checking for XTST... yes
checking for FREETYPE2... yes
checking for LIBFFI... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating nss.cfg
config.status: creating javac
config.status: creating javap
config.status: creating jvm.cfg
config.status: creating ergo.c
config.status: creating tz.properties
config.status: creating jconsole.desktop
config.status: creating policytool.desktop
config.status: executing depfiles commands
===>  Building for icedtea6-1.11.1
mkdir -p stamps ;  if test "xno" != "xno"; then  no -O2 -pipe -fno-strict-aliasing -std=gnu89  -Wl,-Bsymbolic -findirect-dispatch -o native-ecj  --main=org.eclipse.jdt.internal.compiler.batch.Main /usr/local/share/java/classes/ecj-3.7.2.jar ;  fi ;  touch stamps/native-ecj.stamp
mkdir -p /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/bootstrap/ecj/bin stamps/
ln -sf /usr/local/jdk1.6.0/bin/java /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/bootstrap/ecj/bin/java
ln -sf /usr/local/jdk1.6.0/bin/javah /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/bootstrap/ecj/bin/javah
ln -sf /usr/local/jdk1.6.0/bin/rmic /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/bootstrap/ecj/bin/rmic
ln -sf /usr/local/jdk1.6.0/bin/jar /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/bootstrap/ecj/bin/jar
ln -sf /usr/local/jdk1.6.0/bin/native2ascii /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/bootstrap/ecj/bin/native2ascii
ln -sf /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/javac /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/bootstrap/ecj/bin/javac
ln -sf /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/javap /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/bootstrap/ecj/bin/javap
mkdir -p /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/bootstrap/ecj/jre/lib &&  cp /usr/local/jdk1.6.0/jre/lib/rt.jar /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/bootstrap/ecj/jre/lib/rt.jar &&  ln -sf /usr/local/jdk1.6.0/jre/lib/amd64  /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/bootstrap/ecj/jre/lib/ &&  if ! test -d /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/bootstrap/ecj/jre/lib/amd64;  then  ln -sf ./amd64  /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/bootstrap/ecj/jre/lib/amd64;  fi;
mkdir -p /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/bootstrap/ecj/include &&  for i in /usr/local/jdk1.6.0/include/*; do  test -r $i | continue;  i=`basename $i`;  rm -f /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/bootstrap/ecj/include/$i;  ln -s /usr/local/jdk1.6.0/include/$i /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/bootstrap/ecj/include/$i;  done
mkdir -p /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/bootstrap/ecj/lib &&  ln -sf /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/bootstrap/ecj/jre/lib/rt.jar /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/bootstrap/ecj/lib/tools.jar
mkdir -p stamps
touch stamps/bootstrap-directory-ecj.stamp
rm -f /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/bootstrap/jdk1.6.0
ln -sf /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/bootstrap/ecj /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/bootstrap/jdk1.6.0
mkdir -p stamps
touch stamps/bootstrap-directory-symlink-ecj.stamp
mkdir -p drops
ln -sf /usr/ports/distfiles/jaxp144_03.zip drops/jaxp144_03.zip
if ! echo "c1a5348e17b330a7e4b18431e61a40efd2ba99a7da71102cf2c604478ef96012  drops/jaxp144_03.zip"  | /sbin/sha256 -q ;  then  if [ -f drops/jaxp144_03.zip ] ;  then  mv drops/jaxp144_03.zip drops/jaxp144_03.zip.old ;  fi ;  /usr/local/bin/wget http://icedtea.classpath.org/download/drops/jaxp144_03.zip -O drops/jaxp144_03.zip;  if ! echo "c1a5348e17b330a7e4b18431e61a40efd2ba99a7da71102cf2c604478ef96012  drops/jaxp144_03.zip"  | /sbin/sha256 -q ;  then echo "ERROR: Bad download of jaxp drop zip"; false;  fi;  fi ;
6c74f8eac6ca56ac1a0f2d2e9390530bdee2c03c371451cbabd1bb68fbb6598a
mkdir -p stamps
touch stamps/download-jaxp-drop.stamp
mkdir -p drops
ln -sf /usr/ports/distfiles/jdk6-jaxws2_1_6-2011_06_13.zip drops/jdk6-jaxws2_1_6-2011_06_13.zip
if ! echo "229040544e791f44906e8e7b6f6faf503c730a5d854275135f3925490d5c3be3  drops/jdk6-jaxws2_1_6-2011_06_13.zip"  | /sbin/sha256 -q ;  then  if [ -f drops/jdk6-jaxws2_1_6-2011_06_13.zip ] ;  then  mv drops/jdk6-jaxws2_1_6-2011_06_13.zip drops/jdk6-jaxws2_1_6-2011_06_13.zip.old ;  fi ;  /usr/local/bin/wget http://icedtea.classpath.org/download/drops/jdk6-jaxws2_1_6-2011_06_13.zip -O drops/jdk6-jaxws2_1_6-2011_06_13.zip;  if ! echo "229040544e791f44906e8e7b6f6faf503c730a5d854275135f3925490d5c3be3  drops/jdk6-jaxws2_1_6-2011_06_13.zip"  | /sbin/sha256 -q ;  then echo "ERROR: Bad download of jaxws drop zip"; false;  fi;  fi ;
819ad775a137ec311e1f5d58bb63c45c476e4f827c7709c7c623527a5d726a2b
mkdir -p stamps
touch stamps/download-jaxws-drop.stamp
mkdir -p drops
ln -sf /usr/ports/distfiles/jdk6-jaf-b20.zip drops/jdk6-jaf-b20.zip
if ! echo "78c7b5c9d6271e88ee46abadd018a61f1e9645f8936cc8df1617e5f4f5074012  drops/jdk6-jaf-b20.zip"  | /sbin/sha256 -q ;  then  if [ -f drops/jdk6-jaf-b20.zip ] ;  then  mv drops/jdk6-jaf-b20.zip drops/jdk6-jaf-b20.zip.old ;  fi ;  /usr/local/bin/wget http://icedtea.classpath.org/download/drops/jdk6-jaf-b20.zip -O drops/jdk6-jaf-b20.zip;  if ! echo "78c7b5c9d6271e88ee46abadd018a61f1e9645f8936cc8df1617e5f4f5074012  drops/jdk6-jaf-b20.zip"  | /sbin/sha256 -q ;  then echo "ERROR: Bad download of jaf drop zip"; false;  fi;  fi ;
0920f61f02b6a0e57cd1df9ee6c76e84b2b9bcda0c6405779d57e493188d89a3
mkdir -p stamps
touch stamps/download-jaf-drop.stamp
mkdir -p stamps
touch stamps/download-drops.stamp
mkdir -p stamps
touch stamps/download-cacao.stamp
mkdir -p stamps
touch stamps/download-jamvm.stamp
mkdir -p stamps
touch stamps/hgforest.stamp
ln -sf /usr/ports/distfiles/openjdk-6-src-b24-14_nov_2011.tar.gz openjdk-6-src-b24-14_nov_2011.tar.gz
mkdir -p stamps
touch stamps/download-openjdk.stamp
mkdir -p stamps
touch stamps/download-hotspot.stamp
touch stamps/download.stamp
set -e ;  if ! test -d openjdk ;  then  mkdir openjdk ;  /usr/bin/tar xf openjdk-6-src-b24-14_nov_2011.tar.gz -C openjdk;  chmod -R ug+w openjdk ;  sh /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/fsg.sh ;  fi
Further liberating OpenJDK...
mkdir -p stamps
touch stamps/extract-openjdk.stamp
mkdir -p stamps
touch stamps/extract-cacao.stamp
mkdir -p stamps
touch stamps/extract-jamvm.stamp
mkdir -p stamps
touch stamps/extract.stamp
mkdir -p stamps
touch stamps/replace-hotspot.stamp
for target in /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/arm_port/hotspot/tools  /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/arm_port/hotspot/src/*cpu/* ; do  link=$(dirname $target | sed 's/^.*arm_port/openjdk/');  cp -rv -l $target $link;  chmod -R ug+rwX $link;  done
/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/arm_port/hotspot/tools -> openjdk/hotspot/tools
/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/arm_port/hotspot/tools/mkbc.c -> openjdk/hotspot/tools/mkbc.c
/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/arm_port/hotspot/src/cpu/zero -> openjdk/hotspot/src/cpu/zero
/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/arm_port/hotspot/src/cpu/zero/vm -> openjdk/hotspot/src/cpu/zero/vm
/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/arm_port/hotspot/src/cpu/zero/vm/thumb2.cpp -> openjdk/hotspot/src/cpu/zero/vm/thumb2.cpp
/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/arm_port/hotspot/src/cpu/zero/vm/cppInterpreter_arm.S -> openjdk/hotspot/src/cpu/zero/vm/cppInterpreter_arm.S
/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/arm_port/hotspot/src/cpu/zero/vm/asm_helper.cpp -> openjdk/hotspot/src/cpu/zero/vm/asm_helper.cpp
/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/arm_port/hotspot/src/cpu/zero/vm/bytecodes_arm.def -> openjdk/hotspot/src/cpu/zero/vm/bytecodes_arm.def
mkdir -p stamps
touch stamps/ports.stamp
if [ ! -e /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/generated.build ]; then  cp -a /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/generated /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/generated.build &&  chmod -R ug+rwX /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/generated.build ;  fi
mkdir -p stamps
touch stamps/generated.stamp
cp openjdk/jdk/src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.properties openjdk/jdk/src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.9.properties
cp openjdk/jdk/src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.properties openjdk/jdk/src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.10.properties
cp openjdk/jdk/src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.properties openjdk/jdk/src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.11.properties
cp openjdk/jdk/src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.properties openjdk/jdk/src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.12.properties
mkdir -p stamps
touch stamps/fonts.stamp
mkdir -p stamps ;  rm -f stamps/patch-fsg.stamp.tmp ;  touch stamps/patch-fsg.stamp.tmp ;  all_patches_ok=yes;  for p in  ;  do  if test x${all_patches_ok} = "xyes"  && echo Checking $p  && /usr/bin/patch -l -p0 -C -s -t -f  < /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/$p ;  then  echo Applying $p ;  /usr/bin/patch -l -p0 < /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/$p ;  if ! grep "^\* $(basename $p)" /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/HACKING  >> stamps/patch-fsg.stamp.tmp ;  then  echo "* $(basename $p): UNDOCUMENTED"  >> stamps/patch-fsg.stamp.tmp ;  fi ;  else  test x${all_patches_ok} = "xyes" && all_patches_ok=$p ;  fi ;  done ;  mv stamps/patch-fsg.stamp.tmp stamps/patch-fsg.stamp ;  if ! test x${all_patches_ok} = "xyes"; then  echo ERROR patch ${all_patches_ok} FAILED! ;  echo WARNING make clean-patch before retrying a fix ;  exit 2;  fi ;
mkdir -p stamps ;  rm -f stamps/patch.stamp.tmp ;  touch stamps/patch.stamp.tmp ;  all_patches_ok=yes;  for p in patches/security/20120214/7082299.patch  patches/security/20120214/7088367.patch  patches/security/20120214/7110683.patch  patches/security/20120214/7110687.patch  patches/security/20120214/7110700.patch  patches/security/20120214/7110704.patch  patches/security/20120214/7118283.patch  patches/security/20120214/7126960.patch  patches/openjdk/6610244-modal-fatal-error-windows.patch  patches/stdc-limit-macros.patch  patches/openjdk/4993545-nativeinlightfixer.patch  patches/openjdk/6637796-set_bounds.patch  patches/openjdk/6607660-treelock.patch  patches/openjdk/6607170-request_focus.patch  patches/openjdk/4685768-focus.patch  patches/openjdk/6616323-component_array.patch  patches/openjdk/6682046-shape_calculation.patch  patches/openjdk/6797195-hw_lw_mixing.patch  patches/openjdk/6725214-direct3d-01.patch  patches/openjdk/6748082-isDisplayLocal.patch  patches/openjdk/6633275-shaped_translucent_windows.patch  patches/security/20120214/7112642.patch  patches/openjdk/6769607-modal-hangs.patch  patches/openjdk/6791612-opengl-jni-fix.patch  patches/openjdk/6755274-glgetstring-crash.patch  patches/openjdk/6984543-onscreen_rendering_resize_test.patch  patches/openjdk/6693253-security_warning.patch  patches/openjdk/6444769-windowwithwarningtest.patch  patches/notice-safepoints.patch patches/parisc-opt.patch  patches/lucene-crash.patch patches/version.patch  patches/version-hotspot.patch patches/text-relocations.patch  patches/openjdk/7043921-java_rmi_cgi.patch  patches/use-system-tzdata.patch patches/headers.patch  patches/gcc-suffix.patch patches/memory-limits.patch  patches/libraries.patch patches/jvmtiEnv.patch  patches/lcms.patch patches/print_lsb_release.patch  patches/uname.patch patches/freetypeversion.patch  patches/nomotif-6706121.patch patches/nomotif.patch  patches/nomotif-mtoolkit.patch patches/alpha-fixes.patch  patches/alt-jar.patch patches/jdk-use-ssize_t.patch  patches/use-idx_t.patch patches/params-cast-size_t.patch  patches/clean-crypto.patch patches/arch.patch  patches/lc_ctype.patch patches/xjc.patch  patches/linker-libs-order.patch patches/testenv.patch  patches/samejvm-safe.patch patches/pr261.patch  patches/sparc-buildfixes.patch patches/sparc64-linux.patch  patches/sparc-ptracefix.patch patches/sparc-trapsfix.patch  patches/jtreg-6592792.patch patches/s390-noinline.patch  patches/jtreg-dnd.patch patches/jtreg-jrunscript.patch  patches/network-unreachable.patch patches/dnd-filelists.patch  patches/disable-cc-incompatible-sanity-checks.patch  patches/explicit-target-arch.patch  patches/openjdk/7019808-stack_noexec.patch  patches/parisc.patch patches/sh4-support.patch  patches/policy-evaluation.patch  patches/update-bootclasspath.patch  patches/openjdk/6959123-libpng_14.patch  patches/applet_hole.patch patches/jtreg-httpTest.patch  patches/arm.patch patches/debug-dir.patch  patches/override-redirect-metacity.patch  patches/openjdk/6967533-pre_epoch.patch  patches/fonts-rhel.patch patches/fonts-gentoo.patch  patches/ipv4-mapped-ipv6-addresses.patch  patches/jtreg-OpenGLContextInit.patch  patches/openjdk/6510892-httpserver_test.patch  patches/openjdk/6638712-wildcard_types.patch  patches/openjdk/6650759-missing_inference.patch  patches/numa_on_early_glibc.patch  patches/jtreg-international-fonts.patch  patches/f14-fonts.patch patches/jtreg-T6638712-fix.patch  patches/jtreg-T6650759m-fix.patch  patches/openjdk/7003777-bad-html-entity-parse.patch  patches/jtreg-6929067-fix.patch  patches/rendering-engine-tests.patch  patches/openjdk/6800846-printing-quality.patch  patches/rh661505-jpeg.patch  patches/6703377-freetypescaler.patch patches/ia64-fix.patch  patches/openjdk/6642612-filechooser_button_sizes.patch  patches/jtreg-international-fonts-styles.patch  patches/openjdk/6736649-text_bearings.patch  patches/openjdk/6797139-jbutton_truncation.patch  patches/openjdk/6883341-text_bearing_exception.patch  patches/jtreg-png-reader.patch  patches/openjdk/4724552-CubicCurve2D.patch  patches/openjdk/4493128-CubicCurve2D.patch  patches/openjdk/4645692-CubicCurve2D.solveCubic.patch  patches/no-static-linking.patch  patches/openjdk/7041156-gcc_export_dynamic.patch  patches/g344659-sparc_fix.patch  patches/openjdk/6728834-blurred-lcd-aa-text.patch  patches/openjdk/6749060-bad-lcd-aa-non-opaque-dest.patch  patches/openjdk/6708580-exa_slow.patch  patches/openjdk/6896068-sg2d.patch  patches/openjdk/7021314-no_javaws_man_page.patch  patches/pr586-include_all_srcs.patch  patches/jtreg-LastErrorString.patch  patches/openjdk/6663040-com.sun.awt.patch  patches/openjdk/6775317-non-AA-simple-shape-performance.patch  patches/pr600-arm-jvm.cfg.patch  patches/openjdk/6887494-NPE-in-pisces.patch  patches/openjdk/6967436-6967433-floating-pt-conversion.patch  patches/openjdk/6976265-stroke-control.patch  patches/openjdk/6967434-bad-round-joins.patch  patches/openjdk/6766342-AA-simple-shape-performance.patch  patches/openjdk/7016856-pisces-performance.patch  patches/openjdk/6934977-MappedByteBuffer.load.patch  patches/jtreg-hotspot-bug-6196102.patch  patches/jtreg-double-to-string.patch  patches/openjdk/7023591-AAShapePipe.patch  patches/openjdk/7027667-AAShapePipeRegTest.patch  patches/openjdk/7019861-AA-regression-fix.patch  patches/g356743-libpng-1.5.patch patches/revert-6885123.patch  patches/openjdk/7032388-work_without_cmov_instruction.patch  patches/openjdk/7031385-gcc-register-allocation-fix.patch  patches/openjdk/6986968-crash_on_xim_restart.patch  patches/openjdk/7036754-stroker-nan.patch  patches/openjdk/pgram-pipe-regression.patch  patches/openjdk/7034464-hugepage.patch  patches/openjdk/7037939-hugepage.patch  patches/openjdk/7043564-hugepage.patch  patches/openjdk/mutter.patch patches/fonts-rhel-version.patch  patches/openjdk/7036148-npe-null-jmenu-name.patch  patches/jtreg-ChangeDir.patch patches/jtreg-TempBuffer.patch  patches/jtreg-EncodedMultiByteChar.patch  patches/jtreg-FileLoaderTest.patch patches/jtreg-FileMap.patch  patches/jtreg-ChannelsWrite.patch  patches/jtreg-bug7036148-test.patch  patches/jtreg-ReadWriteProfileTest.patch  patches/openjdk/6818312-com.sun.awt.SecurityWarning.getSize.patch  patches/jtreg-MappedByteBuffer-Basic.patch  patches/openjdk/7008106-WindowOpacity.patch  patches/openjdk/6956668-misbehavior_of_XOR_operator_with_int.patch  patches/openjdk/6699843-IllegalArgumentException_drawString.patch  patches/openjdk/6918065-Crash_in_Java2D_blit_loop.patch  patches/openjdk/6623219-Font_canDisplayUpTo_does_not_work.patch  patches/support_linux_3.patch  patches/openjdk/6783910-java_awt_Color_brighter_darker_fix.patch  patches/openjdk/6785424-SecurityException_locating_physical_fonts.patch  patches/openjdk/7047069-Array_can_dynamically_change_size.patch  patches/openjdk/6796786-invalid_FP_identity_transform.patch  patches/openjdk/7042070-Typo_in_Test6796786.patch  patches/openjdk/6679308-Poor_text_rendering_on_translucent_image.patch  patches/openjdk/6842838-64-bit_failure_in_handling_invalid_manifest.patch  patches/openjdk/6882768-test_for_6842838_is_broken.patch  patches/pr639-broken_shark_build.patch  patches/powerpc-stacksize.patch  patches/jtreg-remove-test-6987555.patch  patches/jtreg-remove-test-6991596.patch  patches/openjdk/7036220-shark_llvm_29_headers.patch  patches/openjdk/7029152-String_intrinsics_miss_optimization.patch  patches/openjdk/6711682-JCheckBox_in_JTable_does_not_respond_to_click.patch  patches/openjdk/6758179-D3D_AlphaComposite_is_applied_incorrectly.patch  patches/jtreg-ConstructDeflaterInput-fix.patch  patches/openjdk/6613904-GroupLayout_createParallelGroup_null_arg.patch  patches/openjdk/7049339-anyblit-broken.patch  patches/jtreg-hotspot-Test7020373-fix.patch  patches/openjdk/4917091-javac_rejects_array_over_128_in_length.patch  patches/openjdk/6390045-error_cannot_access_java_lang_void.patch  patches/openjdk/6752638-preferLocaleFonts_throws_NPE.patch  patches/openjdk/5047314-Collator_compare_runs_indefinitely.patch  patches/openjdk/6669869-Beans_isDesignTime_should_be_per-AppContext.patch  patches/openjdk/6934356-Vector_writeObject_serialization_DL.patch  patches/openjdk/7036582-Improve_test_coverage_of_BigDecimal.patch  patches/pr690-shark-jit-hs20.patch  patches/pr696-zero-fast_aldc-hs20.patch  patches/openjdk/6806261-BigDecimal_longValueExact_throws_NPE.patch  patches/openjdk/6371401-BigInteger.shift_throws_StackOverflowError.patch  patches/openjdk/6826104-npe_on_app_and_toolkit_modal_dialog_click.patch  patches/openjdk/5082756-ImageIO_plugins_metadata_boolean_attributes.patch  patches/openjdk/6296893-BMP_Writer_handles_TopDown_prop_incorrectly.patch  patches/openjdk/7103224-glibc_name_collision.patch  patches/arm-debug.patch patches/arm-hsdis.patch  patches/openjdk/7103610-_NET_WM_PID_and_WM_CLIENT_MACHINE_are_not_set.patch  patches/openjdk/7102369-7094468-rmiregistry.patch  patches/openjdk/6851973-kerberos.patch  patches/openjdk/7091528-javadoc_class_files.patch  patches/openjdk/7103725-ssl_beast_regression.patch  patches/openjdk/7140882-dont-return-booleans-from-methods-returning-pointers.patch  patches/openjdk/remove-mimpure-option-to-gcc.patch  patches/rhino.patch     patches/openjdk/6307603-xrender-01.patch  patches/openjdk/6961633-xrender-02.patch  patches/openjdk/7018387-xrender_gc_leak.patch    patches/nss-not-enabled-config.patch    ;  do  if test x${all_patches_ok} = "xyes"  && echo Checking $p  && /usr/bin/patch -l -p0 -C -s -t -f  < /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/$p ;  then  echo Applying $p ;  /usr/bin/patch -l -p0 < /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/$p ;  if ! grep "^\* $(basename $p)" /usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/HACKING  >> stamps/patch.stamp.tmp ;  then  echo "* $(basename $p): UNDOCUMENTED"  >> stamps/patch.stamp.tmp ;  fi ;  else  test x${all_patches_ok} = "xyes" && all_patches_ok=$p ;  fi ;  done ;  mv stamps/patch.stamp.tmp stamps/patch.stamp ;  if ! test x${all_patches_ok} = "xyes"; then  echo ERROR patch ${all_patches_ok} FAILED! ;  echo WARNING make clean-patch before retrying a fix ;  exit 2;  fi
Checking patches/security/20120214/7082299.patch
Applying patches/security/20120214/7082299.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User robm
|# Date 1322691030 0
|# Node ID ee0f12b18cb8d20c3fb61e96817bde6318a29221
|# Parent  dd8956e41b892ed7102e1d5668781f2c68ea9ac5
|7082299: AtomicReferenceArray should ensure that array is Object[]
|Summary: java.util.concurrent.AtomicReferenceArray needs to ensure that internal array is always Object[].
|Reviewed-by: chegar, coffeys
|
|diff --git a/src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java b/src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java
|--- openjdk/jdk/src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java
|+++ openjdk/jdk/src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java
--------------------------
Patching file openjdk/jdk/src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java using Plan A...
Hunk #1 succeeded at 34.
Hunk #2 succeeded at 50.
Hunk #3 succeeded at 89.
Hunk #4 succeeded at 99.
Hunk #5 succeeded at 119.
Hunk #6 succeeded at 133.
Hunk #7 succeeded at 144.
Hunk #8 succeeded at 157.
Hunk #9 succeeded at 168.
Hunk #10 succeeded at 176.
Hunk #11 succeeded at 205.
done
Checking patches/security/20120214/7088367.patch
Applying patches/security/20120214/7088367.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User amenkov
|# Date 1319622989 -14400
|# Node ID b34a3ed0c8f2f6b9121d38ed330430d913f8a385
|# Parent  cdc68d7a17dd412402b100dc427abbe0a90cf2ab
|7088367: JavaSound security issue (12865443)
|Reviewed-by: denis
|
|diff --git a/src/share/classes/com/sun/media/sound/DirectAudioDevice.java b/src/share/classes/com/sun/media/sound/DirectAudioDevice.java
|--- openjdk/jdk/src/share/classes/com/sun/media/sound/DirectAudioDevice.java
|+++ openjdk/jdk/src/share/classes/com/sun/media/sound/DirectAudioDevice.java
--------------------------
Patching file openjdk/jdk/src/share/classes/com/sun/media/sound/DirectAudioDevice.java using Plan A...
Hunk #1 succeeded at 771.
Hunk #2 succeeded at 1000.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/src/share/classes/com/sun/media/sound/SoftMixingSourceDataLine.java b/src/share/classes/com/sun/media/sound/SoftMixingSourceDataLine.java
|--- openjdk/jdk/src/share/classes/com/sun/media/sound/SoftMixingSourceDataLine.java
|+++ openjdk/jdk/src/share/classes/com/sun/media/sound/SoftMixingSourceDataLine.java
--------------------------
Patching file openjdk/jdk/src/share/classes/com/sun/media/sound/SoftMixingSourceDataLine.java using Plan A...
Hunk #1 succeeded at 130.
done
Checking patches/security/20120214/7110683.patch
Applying patches/security/20120214/7110683.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User skoppar
|# Date 1324575564 28800
|# Node ID e05eb7bee1ce0a44f3e414454e44cd49d77ba9de
|# Parent  bfaa99d5bef813217cdbc6eddcdd511cf53327e7
|7110683: Issues with some KeyboardFocusManager method
|7116384: backout the unallowed changes in the KeyboardFocusManager.java javadoc
|Reviewed-by: ant
|
|diff --git a/src/share/classes/java/awt/KeyboardFocusManager.java b/src/share/classes/java/awt/KeyboardFocusManager.java
|--- openjdk/jdk/src/share/classes/java/awt/KeyboardFocusManager.java
|+++ openjdk/jdk/src/share/classes/java/awt/KeyboardFocusManager.java
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/KeyboardFocusManager.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 476.
Hunk #3 succeeded at 511.
Hunk #4 succeeded at 561.
Hunk #5 succeeded at 644.
Hunk #6 succeeded at 681.
Hunk #7 succeeded at 747.
Hunk #8 succeeded at 779.
Hunk #9 succeeded at 846.
Hunk #10 succeeded at 876.
Hunk #11 succeeded at 1171.
Hunk #12 succeeded at 1196.
Hunk #13 succeeded at 3081.
done
Checking patches/security/20120214/7110687.patch
Applying patches/security/20120214/7110687.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User coffeys
|# Date 1321351078 0
|# Node ID dd8956e41b892ed7102e1d5668781f2c68ea9ac5
|# Parent  e11df26be5fc2c18af5601afc3793f9abc3e2c45
|7110687: (tz) java.util.TimeZone.setDefault() should be controlled by a security manager
|Reviewed-by: okutsu
|
|diff --git a/make/java/java/FILES_java.gmk b/make/java/java/FILES_java.gmk
|--- openjdk/jdk/make/java/java/FILES_java.gmk
|+++ openjdk/jdk/make/java/java/FILES_java.gmk
--------------------------
Patching file openjdk/jdk/make/java/java/FILES_java.gmk using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 448.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/src/share/classes/java/util/TimeZone.java b/src/share/classes/java/util/TimeZone.java
|--- openjdk/jdk/src/share/classes/java/util/TimeZone.java
|+++ openjdk/jdk/src/share/classes/java/util/TimeZone.java
--------------------------
Patching file openjdk/jdk/src/share/classes/java/util/TimeZone.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 43.
Hunk #3 succeeded at 544.
Hunk #4 succeeded at 635.
Hunk #5 succeeded at 732.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/src/share/classes/sun/awt/AppContext.java b/src/share/classes/sun/awt/AppContext.java
|--- openjdk/jdk/src/share/classes/sun/awt/AppContext.java
|+++ openjdk/jdk/src/share/classes/sun/awt/AppContext.java
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/awt/AppContext.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 767.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/src/share/classes/sun/misc/JavaAWTAccess.java b/src/share/classes/sun/misc/JavaAWTAccess.java
|new file mode 100644
|--- /dev/null
|+++ openjdk/jdk/src/share/classes/sun/misc/JavaAWTAccess.java
--------------------------
(Creating file openjdk/jdk/src/share/classes/sun/misc/JavaAWTAccess.java...)
Patching file openjdk/jdk/src/share/classes/sun/misc/JavaAWTAccess.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/src/share/classes/sun/misc/SharedSecrets.java b/src/share/classes/sun/misc/SharedSecrets.java
|--- openjdk/jdk/src/share/classes/sun/misc/SharedSecrets.java
|+++ openjdk/jdk/src/share/classes/sun/misc/SharedSecrets.java
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/misc/SharedSecrets.java using Plan A...
Hunk #1 succeeded at 52.
Hunk #2 succeeded at 139.
done
Checking patches/security/20120214/7110700.patch
Applying patches/security/20120214/7110700.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User dmeetry
|# Date 1325175900 -14400
|# Node ID 3c11966c3da3ec95c80008e4a4cc2ae4ab0e59fc
|# Parent  e05eb7bee1ce0a44f3e414454e44cd49d77ba9de
|7110700: Enhance exception throwing mechanism in ObjectStreamClass
|Reviewed-by: smarks
|
|diff --git a/src/share/classes/java/io/ObjectStreamClass.java b/src/share/classes/java/io/ObjectStreamClass.java
|--- openjdk/jdk/src/share/classes/java/io/ObjectStreamClass.java
|+++ openjdk/jdk/src/share/classes/java/io/ObjectStreamClass.java
--------------------------
Patching file openjdk/jdk/src/share/classes/java/io/ObjectStreamClass.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 730.
Hunk #3 succeeded at 744.
Hunk #4 succeeded at 760.
done
Checking patches/security/20120214/7110704.patch
Applying patches/security/20120214/7110704.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User coffeys
|# Date 1321351683 0
|# Node ID c971de26dc9c900ff5a5ecb799dcc84cf9769ef0
|# Parent  23f471142a033a47b6b60506c2749f9caad0a4f8
|7110704: Issues with some method in corba
|Reviewed-by: dmeetry
|
|diff --git a/src/share/classes/com/sun/corba/se/impl/dynamicany/DynAnyFactoryImpl.java b/src/share/classes/com/sun/corba/se/impl/dynamicany/DynAnyFactoryImpl.java
|--- openjdk/corba/src/share/classes/com/sun/corba/se/impl/dynamicany/DynAnyFactoryImpl.java
|+++ openjdk/corba/src/share/classes/com/sun/corba/se/impl/dynamicany/DynAnyFactoryImpl.java
--------------------------
Patching file openjdk/corba/src/share/classes/com/sun/corba/se/impl/dynamicany/DynAnyFactoryImpl.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 82.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/src/share/classes/com/sun/corba/se/impl/dynamicany/DynAnyImpl.java b/src/share/classes/com/sun/corba/se/impl/dynamicany/DynAnyImpl.java
|--- openjdk/corba/src/share/classes/com/sun/corba/se/impl/dynamicany/DynAnyImpl.java
|+++ openjdk/corba/src/share/classes/com/sun/corba/se/impl/dynamicany/DynAnyImpl.java
--------------------------
Patching file openjdk/corba/src/share/classes/com/sun/corba/se/impl/dynamicany/DynAnyImpl.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 195.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/src/share/classes/com/sun/org/omg/SendingContext/_CodeBaseImplBase.java b/src/share/classes/com/sun/org/omg/SendingContext/_CodeBaseImplBase.java
|--- openjdk/corba/src/share/classes/com/sun/org/omg/SendingContext/_CodeBaseImplBase.java
|+++ openjdk/corba/src/share/classes/com/sun/org/omg/SendingContext/_CodeBaseImplBase.java
--------------------------
Patching file openjdk/corba/src/share/classes/com/sun/org/omg/SendingContext/_CodeBaseImplBase.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 138.
done
Checking patches/security/20120214/7118283.patch
Applying patches/security/20120214/7118283.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User asaha
|# Date 1323826839 28800
|# Node ID 71ca2b40fdc9fd542d565ccd9f2f14861556a417
|# Parent  ee0f12b18cb8d20c3fb61e96817bde6318a29221
|7118283: Better input parameter checking in zip file processing
|Reviewed-by: sherman
|
|diff --git a/src/share/native/java/util/zip/zip_util.c b/src/share/native/java/util/zip/zip_util.c
|--- openjdk/jdk/src/share/native/java/util/zip/zip_util.c
|+++ openjdk/jdk/src/share/native/java/util/zip/zip_util.c
--------------------------
Patching file openjdk/jdk/src/share/native/java/util/zip/zip_util.c using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 450.
done
Checking patches/security/20120214/7126960.patch
Applying patches/security/20120214/7126960.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User coffeys
|# Date 1326712887 0
|# Node ID 2d8dead332cbe169d486ecc70239475ebe3a77f7
|# Parent  a224904d42db1f54139257221e9b545bd1c90b2e
|7126960: Add property to limit number of request headers to the HTTP Server
|Reviewed-by: chegar
|
|diff --git a/src/share/classes/sun/net/httpserver/Request.java b/src/share/classes/sun/net/httpserver/Request.java
|--- openjdk/jdk/src/share/classes/sun/net/httpserver/Request.java
|+++ openjdk/jdk/src/share/classes/sun/net/httpserver/Request.java
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/net/httpserver/Request.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 190.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/src/share/classes/sun/net/httpserver/ServerConfig.java b/src/share/classes/sun/net/httpserver/ServerConfig.java
|--- openjdk/jdk/src/share/classes/sun/net/httpserver/ServerConfig.java
|+++ openjdk/jdk/src/share/classes/sun/net/httpserver/ServerConfig.java
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/net/httpserver/ServerConfig.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 45.
Hunk #3 succeeded at 56.
Hunk #4 succeeded at 98.
Hunk #5 succeeded at 139.
done
Checking patches/openjdk/6610244-modal-fatal-error-windows.patch
Applying patches/openjdk/6610244-modal-fatal-error-windows.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User dav
|# Date 1206447363 -10800
|# Node ID 58c90502785df64cd26e9f2d400429dcfcaa3b91
|# Parent  de9e902b1f24bef3ec7248890caa1722983e68f5
|6610244: modal dialog closes with fatal error if -Xcheck:jni is set
|Summary: obtain WWindowPeer class every time it is required
|Reviewed-by: art
|
|diff -r de9e902b1f24 -r 58c90502785d src/windows/native/sun/windows/awt_Dialog.cpp
|--- openjdk.orig/jdk/src/windows/native/sun/windows/awt_Dialog.cpp	Mon Mar 24 18:24:15 2008 +0300
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_Dialog.cpp	Tue Mar 25 15:16:03 2008 +0300
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_Dialog.cpp using Plan A...
Hunk #1 succeeded at 428.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r de9e902b1f24 -r 58c90502785d src/windows/native/sun/windows/awt_Window.cpp
|--- openjdk.orig/jdk/src/windows/native/sun/windows/awt_Window.cpp	Mon Mar 24 18:24:15 2008 +0300
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_Window.cpp	Tue Mar 25 15:16:03 2008 +0300
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_Window.cpp using Plan A...
Hunk #1 succeeded at 122.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r de9e902b1f24 -r 58c90502785d src/windows/native/sun/windows/awt_Window.h
|--- openjdk.orig/jdk/src/windows/native/sun/windows/awt_Window.h	Mon Mar 24 18:24:15 2008 +0300
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_Window.h	Tue Mar 25 15:16:03 2008 +0300
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_Window.h using Plan A...
Hunk #1 succeeded at 57.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r de9e902b1f24 -r 58c90502785d test/java/awt/Dialog/CrashXCheckJni/CrashXCheckJni.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/java/awt/Dialog/CrashXCheckJni/CrashXCheckJni.java	Tue Mar 25 15:16:03 2008 +0300
--------------------------
(Creating file openjdk/jdk/test/java/awt/Dialog/CrashXCheckJni/CrashXCheckJni.java...)
Patching file openjdk/jdk/test/java/awt/Dialog/CrashXCheckJni/CrashXCheckJni.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  Ignoring the trailing garbage.
done
Checking patches/stdc-limit-macros.patch
Applying patches/stdc-limit-macros.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/hotspot/src/share/vm/utilities/globalDefinitions_gcc.hpp
|+++ openjdk/hotspot/src/share/vm/utilities/globalDefinitions_gcc.hpp
--------------------------
Patching file openjdk/hotspot/src/share/vm/utilities/globalDefinitions_gcc.hpp using Plan A...
Hunk #1 succeeded at 77 (offset 5 lines).
done
Checking patches/openjdk/4993545-nativeinlightfixer.patch
Applying patches/openjdk/4993545-nativeinlightfixer.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User anthony
|# Date 1206000556 -10800
|# Node ID 8aafe588257f91d68436c0e13d98b6f4b27e2436
|# Parent  c267a33e76b0f76b200dbb592ec9671207ee2b5d
|4993545: NativeInLightFixer adds asynchronousity
|Summary: All the hooks related to the NativeInLightFixer have been moved to the HW/LW mixing handling methods. The NativeInLightFixer itself has been removed.
|Reviewed-by: son, alexp
|
|diff -r c267a33e76b0 -r 8aafe588257f src/share/classes/java/awt/Component.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/Component.java	Mon Jan 10 20:08:48 2011 +0000
|+++ openjdk/jdk/src/share/classes/java/awt/Component.java	Thu Mar 20 11:09:16 2008 +0300
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/Component.java using Plan A...
Hunk #1 succeeded at 6521 (offset 28 lines).
Hunk #2 succeeded at 6632 (offset 28 lines).
Hunk #3 succeeded at 8515 (offset 2 lines).
Hunk #4 succeeded at 8566 (offset 28 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r c267a33e76b0 -r 8aafe588257f src/share/classes/java/awt/Container.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/Container.java	Mon Jan 10 20:08:48 2011 +0000
|+++ openjdk/jdk/src/share/classes/java/awt/Container.java	Thu Mar 20 11:09:16 2008 +0300
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/Container.java using Plan A...
Hunk #1 succeeded at 828.
Hunk #2 succeeded at 3938.
Hunk #3 succeeded at 4023.
Hunk #4 succeeded at 4035.
done
Checking patches/openjdk/6637796-set_bounds.patch
Applying patches/openjdk/6637796-set_bounds.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User anthony
|# Date 1295642949 0
|# Node ID fcb2f8dcf112ceaf5d8d18b75749baa22b29bda6
|# Parent  8aafe588257f91d68436c0e13d98b6f4b27e2436
|6637796: setBounds doesn't enlarge Component
|Summary: Added the areBoundsValid() method that verifies whether the current bounds of the component are valid. Using the isValid() method for this purpose previously was incorrect.
|Reviewed-by: son, art
|
|diff -r 8aafe588257f -r fcb2f8dcf112 src/share/classes/java/awt/Component.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/Component.java	Thu Mar 20 11:09:16 2008 +0300
|+++ openjdk/jdk/src/share/classes/java/awt/Component.java	Fri Jan 21 20:49:09 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/Component.java using Plan A...
Hunk #1 succeeded at 9340 (offset 30 lines).
Hunk #2 succeeded at 9375 (offset 30 lines).
Hunk #3 succeeded at 9502 (offset 30 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 8aafe588257f -r fcb2f8dcf112 test/java/awt/Mixing/ValidBounds.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/java/awt/Mixing/ValidBounds.java	Fri Jan 21 20:49:09 2011 +0000
--------------------------
(Creating file openjdk/jdk/test/java/awt/Mixing/ValidBounds.java...)
Patching file openjdk/jdk/test/java/awt/Mixing/ValidBounds.java using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/openjdk/6607660-treelock.patch
Applying patches/openjdk/6607660-treelock.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User anthony
|# Date 1205838628 -10800
|# Node ID 26dd3385e8dca0f8e7e20254e55101d3d904fceb
|# Parent  fcb2f8dcf112ceaf5d8d18b75749baa22b29bda6
|6607660: java.awt.Container.getMouseEventTargetImpl should be invoked while holding the TreeLock
|Summary: The body of the method has been wrapped into the synchronized (getTreeLock()) { } block.
|Reviewed-by: son, art
|
|diff -r fcb2f8dcf112 -r 26dd3385e8dc src/share/classes/java/awt/Container.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/Container.java	Fri Jan 21 20:49:09 2011 +0000
|+++ openjdk/jdk/src/share/classes/java/awt/Container.java	Tue Mar 18 14:10:28 2008 +0300
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/Container.java using Plan A...
Hunk #1 succeeded at 2255.
done
Checking patches/openjdk/6607170-request_focus.patch
Applying patches/openjdk/6607170-request_focus.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User ant
|# Date 1295900434 0
|# Node ID 04fd19f2a82db6eaaa4d63121510d5a47dadffe3
|# Parent  26dd3385e8dca0f8e7e20254e55101d3d904fceb
|6607170: Focus not set by requestFocus
|Summary: fixing/refactoring focus auto-transfer mechanism.
|Reviewed-by: son
|
|diff -r 26dd3385e8dc -r 04fd19f2a82d src/share/classes/java/awt/Component.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/Component.java	Tue Mar 18 14:10:28 2008 +0300
|+++ openjdk/jdk/src/share/classes/java/awt/Component.java	Mon Jan 24 20:20:34 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/Component.java using Plan A...
Hunk #1 succeeded at 1355 (offset 28 lines).
Hunk #2 succeeded at 1524 (offset 28 lines).
Hunk #3 succeeded at 6608 (offset 28 lines).
Hunk #4 succeeded at 6744 (offset 28 lines).
Hunk #5 succeeded at 7399 (offset 28 lines).
Hunk #6 succeeded at 7438 (offset 28 lines).
Hunk #7 succeeded at 7494 (offset 28 lines).
Hunk #8 succeeded at 7515 (offset 28 lines).
Hunk #9 succeeded at 7530 (offset 28 lines).
Hunk #10 succeeded at 7544 (offset 28 lines).
Hunk #11 succeeded at 7552 (offset 28 lines).
Hunk #12 succeeded at 7639 (offset 28 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 26dd3385e8dc -r 04fd19f2a82d src/share/classes/java/awt/Container.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/Container.java	Tue Mar 18 14:10:28 2008 +0300
|+++ openjdk/jdk/src/share/classes/java/awt/Container.java	Mon Jan 24 20:20:34 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/Container.java using Plan A...
Hunk #1 succeeded at 2656.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 26dd3385e8dc -r 04fd19f2a82d src/share/classes/java/awt/DefaultKeyboardFocusManager.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/DefaultKeyboardFocusManager.java	Tue Mar 18 14:10:28 2008 +0300
|+++ openjdk/jdk/src/share/classes/java/awt/DefaultKeyboardFocusManager.java	Mon Jan 24 20:20:34 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/DefaultKeyboardFocusManager.java using Plan A...
Hunk #1 succeeded at 155.
Hunk #2 succeeded at 506.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 26dd3385e8dc -r 04fd19f2a82d src/share/classes/java/awt/KeyboardFocusManager.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/KeyboardFocusManager.java	Tue Mar 18 14:10:28 2008 +0300
|+++ openjdk/jdk/src/share/classes/java/awt/KeyboardFocusManager.java	Mon Jan 24 20:20:34 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/KeyboardFocusManager.java using Plan A...
Hunk #1 succeeded at 2559 (offset -21 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 26dd3385e8dc -r 04fd19f2a82d src/solaris/classes/sun/awt/X11/XKeyboardFocusManagerPeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/XKeyboardFocusManagerPeer.java	Tue Mar 18 14:10:28 2008 +0300
|+++ openjdk/jdk/src/solaris/classes/sun/awt/X11/XKeyboardFocusManagerPeer.java	Mon Jan 24 20:20:34 2011 +0000
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/X11/XKeyboardFocusManagerPeer.java using Plan A...
Hunk #1 succeeded at 96.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 26dd3385e8dc -r 04fd19f2a82d src/windows/native/sun/windows/awt_Component.cpp
|--- openjdk.orig/jdk/src/windows/native/sun/windows/awt_Component.cpp	Tue Mar 18 14:10:28 2008 +0300
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_Component.cpp	Mon Jan 24 20:20:34 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_Component.cpp using Plan A...
Hunk #1 succeeded at 901.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 26dd3385e8dc -r 04fd19f2a82d test/java/awt/Focus/ContainerFocusAutoTransferTest/ContainerFocusAutoTransferTest.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/java/awt/Focus/ContainerFocusAutoTransferTest/ContainerFocusAutoTransferTest.java	Mon Jan 24 20:20:34 2011 +0000
--------------------------
(Creating file openjdk/jdk/test/java/awt/Focus/ContainerFocusAutoTransferTest/ContainerFocusAutoTransferTest.java...)
Patching file openjdk/jdk/test/java/awt/Focus/ContainerFocusAutoTransferTest/ContainerFocusAutoTransferTest.java using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/openjdk/4685768-focus.patch
Applying patches/openjdk/4685768-focus.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User ant
|# Date 1213695448 -14400
|# Node ID a9b5b5d105a8e613fe8ebacba01fa010ff087d3e
|# Parent  58a2ba2767bef1b7ca6d994d94c0812216b4f5ad
|4685768: A11y issue - Focus set to disabled component, can't Tab/Shift-Tab
|Summary: The restore-focus procedure should skip disabled components.
|Reviewed-by: art, dcherepanov
|
|diff -r 58a2ba2767be -r a9b5b5d105a8 src/share/classes/java/awt/Component.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/Component.java	Wed Jun 11 01:31:42 2008 -0700
|+++ openjdk/jdk/src/share/classes/java/awt/Component.java	Tue Jun 17 13:37:28 2008 +0400
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/Component.java using Plan A...
Hunk #1 succeeded at 7486 (offset -2 lines).
Hunk #2 succeeded at 7535 (offset -2 lines).
Hunk #3 succeeded at 8516 (offset 2 lines).
Hunk #4 succeeded at 8529 (offset -2 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 58a2ba2767be -r a9b5b5d105a8 src/share/classes/java/awt/Container.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/Container.java	Wed Jun 11 01:31:42 2008 -0700
|+++ openjdk/jdk/src/share/classes/java/awt/Container.java	Tue Jun 17 13:37:28 2008 +0400
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/Container.java using Plan A...
Hunk #1 succeeded at 856 (offset -4 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 58a2ba2767be -r a9b5b5d105a8 src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java	Wed Jun 11 01:31:42 2008 -0700
|+++ openjdk/jdk/src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java	Tue Jun 17 13:37:28 2008 +0400
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java using Plan A...
Hunk #1 succeeded at 467 (offset -89 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 58a2ba2767be -r a9b5b5d105a8 src/share/classes/java/awt/DefaultKeyboardFocusManager.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/DefaultKeyboardFocusManager.java	Wed Jun 11 01:31:42 2008 -0700
|+++ openjdk/jdk/src/share/classes/java/awt/DefaultKeyboardFocusManager.java	Tue Jun 17 13:37:28 2008 +0400
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/DefaultKeyboardFocusManager.java using Plan A...
Hunk #1 succeeded at 154.
Hunk #2 succeeded at 501 (offset 1 line).
Hunk #3 succeeded at 751 (offset 6 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 58a2ba2767be -r a9b5b5d105a8 src/share/classes/java/awt/Window.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/Window.java	Wed Jun 11 01:31:42 2008 -0700
|+++ openjdk/jdk/src/share/classes/java/awt/Window.java	Tue Jun 17 13:37:28 2008 +0400
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/Window.java using Plan A...
Hunk #1 succeeded at 3026 (offset -119 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 58a2ba2767be -r a9b5b5d105a8 test/java/awt/Focus/NoAutotransferToDisabledCompTest/NoAutotransferToDisabledCompTest.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/java/awt/Focus/NoAutotransferToDisabledCompTest/NoAutotransferToDisabledCompTest.java	Tue Jun 17 13:37:28 2008 +0400
--------------------------
(Creating file openjdk/jdk/test/java/awt/Focus/NoAutotransferToDisabledCompTest/NoAutotransferToDisabledCompTest.java...)
Patching file openjdk/jdk/test/java/awt/Focus/NoAutotransferToDisabledCompTest/NoAutotransferToDisabledCompTest.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 58a2ba2767be -r a9b5b5d105a8 test/java/awt/Focus/RequestFocusToDisabledCompTest/RequestFocusToDisabledCompTest.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/java/awt/Focus/RequestFocusToDisabledCompTest/RequestFocusToDisabledCompTest.java	Tue Jun 17 13:37:28 2008 +0400
--------------------------
(Creating file openjdk/jdk/test/java/awt/Focus/RequestFocusToDisabledCompTest/RequestFocusToDisabledCompTest.java...)
Patching file openjdk/jdk/test/java/awt/Focus/RequestFocusToDisabledCompTest/RequestFocusToDisabledCompTest.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 58a2ba2767be -r a9b5b5d105a8 test/java/awt/regtesthelpers/Util.java
|--- openjdk.orig/jdk/test/java/awt/regtesthelpers/Util.java	Wed Jun 11 01:31:42 2008 -0700
|+++ openjdk/jdk/test/java/awt/regtesthelpers/Util.java	Tue Jun 17 13:37:28 2008 +0400
--------------------------
Patching file openjdk/jdk/test/java/awt/regtesthelpers/Util.java using Plan A...
Hunk #1 succeeded at 124.
Hunk #2 succeeded at 582.
Hmm...  Ignoring the trailing garbage.
done
Checking patches/openjdk/6616323-component_array.patch
Applying patches/openjdk/6616323-component_array.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User dav
|# Date 1296583142 0
|# Node ID 5dab44569221369c0353129cd4fac0c3f259f258
|# Parent  04fd19f2a82db6eaaa4d63121510d5a47dadffe3
|6616323: consider benefits of replacing a component array with other collection from the awt.Container class
|7015232: missing copyright header in CheckZOrderChange.java
|Reviewed-by: uta, art, anthony
|
|diff -r 04fd19f2a82d -r 5dab44569221 src/share/classes/java/awt/Component.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/Component.java	Mon Jan 24 20:20:34 2011 +0000
|+++ openjdk/jdk/src/share/classes/java/awt/Component.java	Tue Feb 01 17:59:02 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/Component.java using Plan A...
Hunk #1 succeeded at 2154 (offset 28 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 04fd19f2a82d -r 5dab44569221 src/share/classes/java/awt/Container.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/Container.java	Mon Jan 24 20:20:34 2011 +0000
|+++ openjdk/jdk/src/share/classes/java/awt/Container.java	Tue Feb 01 17:59:02 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/Container.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 44.
Hunk #3 succeeded at 88.
Hunk #4 succeeded at 281.
Hunk #5 succeeded at 295.
Hunk #6 succeeded at 315.
Hunk #7 succeeded at 415.
Hunk #8 succeeded at 453.
Hunk #9 succeeded at 503.
Hunk #10 succeeded at 777.
Hunk #11 succeeded at 791.
Hunk #12 succeeded at 893.
Hunk #13 succeeded at 1028.
Hunk #14 succeeded at 1041.
Hunk #15 succeeded at 1099.
Hunk #16 succeeded at 1131.
Hunk #17 succeeded at 1149.
Hunk #18 succeeded at 1194.
Hunk #19 succeeded at 1218.
Hunk #20 succeeded at 1259.
Hunk #21 succeeded at 1271.
Hunk #22 succeeded at 1334.
Hunk #23 succeeded at 1367.
Hunk #24 succeeded at 1379.
Hunk #25 succeeded at 1521.
Hunk #26 succeeded at 1544.
Hunk #27 succeeded at 1796.
Hunk #28 succeeded at 1851.
Hunk #29 succeeded at 1864.
Hunk #30 succeeded at 1886.
Hunk #31 succeeded at 1900.
Hunk #32 succeeded at 1922.
Hunk #33 succeeded at 2218.
Hunk #34 succeeded at 2371.
Hunk #35 succeeded at 2380.
Hunk #36 succeeded at 2500.
Hunk #37 succeeded at 2588.
Hunk #38 succeeded at 2618.
Hunk #39 succeeded at 2647.
Hunk #40 succeeded at 2837.
Hunk #41 succeeded at 2863.
Hunk #42 succeeded at 3378.
Hunk #43 succeeded at 3500.
Hunk #44 succeeded at 3540.
Hunk #45 succeeded at 3555.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 04fd19f2a82d -r 5dab44569221 src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java	Mon Jan 24 20:20:34 2011 +0000
|+++ openjdk/jdk/src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java	Tue Feb 01 17:59:02 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java using Plan A...
Hunk #1 succeeded at 135.
Hunk #2 succeeded at 242.
Hunk #3 succeeded at 321.
Hunk #4 succeeded at 370.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 04fd19f2a82d -r 5dab44569221 src/share/classes/java/awt/ScrollPane.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/ScrollPane.java	Mon Jan 24 20:20:34 2011 +0000
|+++ openjdk/jdk/src/share/classes/java/awt/ScrollPane.java	Tue Feb 01 17:59:02 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/ScrollPane.java using Plan A...
Hunk #1 succeeded at 354.
Hunk #2 succeeded at 389.
Hunk #3 succeeded at 484.
Hunk #4 succeeded at 514.
Hunk #5 succeeded at 589.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 04fd19f2a82d -r 5dab44569221 src/windows/native/sun/windows/awt_Container.cpp
|--- openjdk.orig/jdk/src/windows/native/sun/windows/awt_Container.cpp	Mon Jan 24 20:20:34 2011 +0000
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_Container.cpp	Tue Feb 01 17:59:02 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_Container.cpp using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 30.
Hunk #3 succeeded at 43.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 04fd19f2a82d -r 5dab44569221 src/windows/native/sun/windows/awt_Container.h
|--- openjdk.orig/jdk/src/windows/native/sun/windows/awt_Container.h	Mon Jan 24 20:20:34 2011 +0000
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_Container.h	Tue Feb 01 17:59:02 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_Container.h using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 37.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 04fd19f2a82d -r 5dab44569221 test/java/awt/Container/CheckZOrderChange/CheckZOrderChange.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/java/awt/Container/CheckZOrderChange/CheckZOrderChange.java	Tue Feb 01 17:59:02 2011 +0000
--------------------------
(Creating file openjdk/jdk/test/java/awt/Container/CheckZOrderChange/CheckZOrderChange.java...)
Patching file openjdk/jdk/test/java/awt/Container/CheckZOrderChange/CheckZOrderChange.java using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/openjdk/6682046-shape_calculation.patch
Applying patches/openjdk/6682046-shape_calculation.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User anthony
|# Date 1292028654 0
|# Node ID 6de73ab429ca5638f4761c98f15a92dda7327d09
|# Parent  5dab44569221369c0353129cd4fac0c3f259f258
|6682046: Mixing code does not always recalculate shapes correctly when resizing components
|Summary: The valid property is now encapsulated in Component.
|Reviewed-by: art
|
|diff -r 5dab44569221 -r 6de73ab429ca src/share/classes/java/awt/Button.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/Button.java	Tue Feb 01 17:59:02 2011 +0000
|+++ openjdk/jdk/src/share/classes/java/awt/Button.java	Sat Dec 11 00:50:54 2010 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/Button.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 213.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 5dab44569221 -r 6de73ab429ca src/share/classes/java/awt/Checkbox.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/Checkbox.java	Tue Feb 01 17:59:02 2011 +0000
|+++ openjdk/jdk/src/share/classes/java/awt/Checkbox.java	Sat Dec 11 00:50:54 2010 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/Checkbox.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 284.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 5dab44569221 -r 6de73ab429ca src/share/classes/java/awt/Choice.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/Choice.java	Tue Feb 01 17:59:02 2011 +0000
|+++ openjdk/jdk/src/share/classes/java/awt/Choice.java	Sat Dec 11 00:50:54 2010 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/Choice.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 207.
Hunk #3 succeeded at 267.
Hunk #4 succeeded at 295.
Hunk #5 succeeded at 317.
Hunk #6 succeeded at 359.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 5dab44569221 -r 6de73ab429ca src/share/classes/java/awt/Component.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/Component.java	Tue Feb 01 17:59:02 2011 +0000
|+++ openjdk/jdk/src/share/classes/java/awt/Component.java	Sat Dec 11 00:50:54 2010 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/Component.java using Plan A...
Hunk #1 succeeded at 347 (offset 2 lines).
Hunk #2 succeeded at 1725 (offset 26 lines).
Hunk #3 succeeded at 1760 (offset 2 lines).
Hunk #4 succeeded at 2093 (offset 26 lines).
Hunk #5 succeeded at 2639 (offset 2 lines).
Hunk #6 succeeded at 2675 (offset 26 lines).
Hunk #7 succeeded at 2682 (offset 2 lines).
Hunk #8 succeeded at 7722 (offset 22 lines).
Hunk #9 succeeded at 8464 (offset 4 lines).
Hunk #10 succeeded at 9332 (offset 30 lines).
Hunk #11 succeeded at 9578 (offset 4 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 5dab44569221 -r 6de73ab429ca src/share/classes/java/awt/Container.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/Container.java	Tue Feb 01 17:59:02 2011 +0000
|+++ openjdk/jdk/src/share/classes/java/awt/Container.java	Sat Dec 11 00:50:54 2010 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/Container.java using Plan A...
Hunk #1 succeeded at 505.
Hunk #2 succeeded at 794.
Hunk #3 succeeded at 1056.
Hunk #4 succeeded at 1145.
Hunk #5 succeeded at 1237.
Hunk #6 succeeded at 1397.
Hunk #7 succeeded at 1469.
Hunk #8 succeeded at 1481.
Hunk #9 succeeded at 1503.
Hunk #10 succeeded at 1512.
Hunk #11 succeeded at 1522.
Hunk #12 succeeded at 1537.
Hunk #13 succeeded at 4062.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 5dab44569221 -r 6de73ab429ca src/share/classes/java/awt/Dialog.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/Dialog.java	Tue Feb 01 17:59:02 2011 +0000
|+++ openjdk/jdk/src/share/classes/java/awt/Dialog.java	Sat Dec 11 00:50:54 2010 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/Dialog.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 1327.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 5dab44569221 -r 6de73ab429ca src/share/classes/java/awt/Frame.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/Frame.java	Tue Feb 01 17:59:02 2011 +0000
|+++ openjdk/jdk/src/share/classes/java/awt/Frame.java	Sat Dec 11 00:50:54 2010 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/Frame.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 590.
Hunk #3 succeeded at 631.
Hunk #4 succeeded at 856.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 5dab44569221 -r 6de73ab429ca src/share/classes/java/awt/Label.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/Label.java	Tue Feb 01 17:59:02 2011 +0000
|+++ openjdk/jdk/src/share/classes/java/awt/Label.java	Sat Dec 11 00:50:54 2010 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/Label.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 257.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 5dab44569221 -r 6de73ab429ca src/share/classes/java/awt/TextField.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/TextField.java	Tue Feb 01 17:59:02 2011 +0000
|+++ openjdk/jdk/src/share/classes/java/awt/TextField.java	Sat Dec 11 00:50:54 2010 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/TextField.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 296.
done
Checking patches/openjdk/6797195-hw_lw_mixing.patch
Applying patches/openjdk/6797195-hw_lw_mixing.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/sun/awt/Makefile openjdk/jdk/make/sun/awt/Makefile
|--- openjdk.orig/jdk/make/sun/awt/Makefile	2011-01-20 23:54:06.000000000 +0000
|+++ openjdk/jdk/make/sun/awt/Makefile	2011-02-16 00:36:10.750531044 +0000
--------------------------
Patching file openjdk/jdk/make/sun/awt/Makefile using Plan A...
Hunk #1 succeeded at 51.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/tools/sharing/classlist.linux openjdk/jdk/make/tools/sharing/classlist.linux
|--- openjdk.orig/jdk/make/tools/sharing/classlist.linux	2011-01-20 23:54:06.000000000 +0000
|+++ openjdk/jdk/make/tools/sharing/classlist.linux	2011-02-16 00:36:10.758530424 +0000
--------------------------
Patching file openjdk/jdk/make/tools/sharing/classlist.linux using Plan A...
Hunk #1 succeeded at 1718.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/tools/sharing/classlist.solaris openjdk/jdk/make/tools/sharing/classlist.solaris
|--- openjdk.orig/jdk/make/tools/sharing/classlist.solaris	2011-01-20 23:54:06.000000000 +0000
|+++ openjdk/jdk/make/tools/sharing/classlist.solaris	2011-02-16 00:36:10.758530424 +0000
--------------------------
Patching file openjdk/jdk/make/tools/sharing/classlist.solaris using Plan A...
Hunk #1 succeeded at 961.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/tools/sharing/classlist.windows openjdk/jdk/make/tools/sharing/classlist.windows
|--- openjdk.orig/jdk/make/tools/sharing/classlist.windows	2011-01-20 23:54:06.000000000 +0000
|+++ openjdk/jdk/make/tools/sharing/classlist.windows	2011-02-16 00:36:10.758530424 +0000
--------------------------
Patching file openjdk/jdk/make/tools/sharing/classlist.windows using Plan A...
Hunk #1 succeeded at 1621.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/classes/com/sun/awt/AWTUtilities.java openjdk/jdk/src/share/classes/com/sun/awt/AWTUtilities.java
|--- openjdk.orig/jdk/src/share/classes/com/sun/awt/AWTUtilities.java	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/src/share/classes/com/sun/awt/AWTUtilities.java	2011-02-16 00:36:10.758530424 +0000
--------------------------
(Creating file openjdk/jdk/src/share/classes/com/sun/awt/AWTUtilities.java...)
Patching file openjdk/jdk/src/share/classes/com/sun/awt/AWTUtilities.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/classes/java/awt/Component.java openjdk/jdk/src/share/classes/java/awt/Component.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/Component.java	2011-02-16 00:32:37.000000000 +0000
|+++ openjdk/jdk/src/share/classes/java/awt/Component.java	2011-02-16 00:36:10.762530115 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/Component.java using Plan A...
Hunk #1 succeeded at 66.
Hunk #2 succeeded at 763.
Hunk #3 succeeded at 812.
Hunk #4 succeeded at 6613.
Hunk #5 succeeded at 6704.
Hunk #6 succeeded at 9374 (offset 4 lines).
Hunk #7 succeeded at 9385 (offset 4 lines).
Hunk #8 succeeded at 9402 (offset 4 lines).
Hunk #9 succeeded at 9449 (offset 4 lines).
Hunk #10 succeeded at 9475 (offset 4 lines).
Hunk #11 succeeded at 9508 (offset 4 lines).
Hunk #12 succeeded at 9520 (offset 4 lines).
Hunk #13 succeeded at 9547 (offset 4 lines).
Hunk #14 succeeded at 9573 (offset 4 lines).
Hunk #15 succeeded at 9594 (offset 4 lines).
Hunk #16 succeeded at 9655 (offset 4 lines).
Hunk #17 succeeded at 9669 (offset 4 lines).
Hunk #18 succeeded at 9689 (offset 4 lines).
Hunk #19 succeeded at 9711 (offset 4 lines).
Hunk #20 succeeded at 9722 (offset 4 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/classes/java/awt/Container.java openjdk/jdk/src/share/classes/java/awt/Container.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/Container.java	2011-02-16 00:32:37.000000000 +0000
|+++ openjdk/jdk/src/share/classes/java/awt/Container.java	2011-02-16 00:36:10.762530115 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/Container.java using Plan A...
Hunk #1 succeeded at 569.
Hunk #2 succeeded at 580.
Hunk #3 succeeded at 3857.
Hunk #4 succeeded at 3896.
Hunk #5 succeeded at 3933.
Hunk #6 succeeded at 4036.
Hunk #7 succeeded at 4074.
Hunk #8 succeeded at 4087.
Hunk #9 succeeded at 4111.
Hunk #10 succeeded at 4131.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/classes/javax/swing/JRootPane.java openjdk/jdk/src/share/classes/javax/swing/JRootPane.java
|--- openjdk.orig/jdk/src/share/classes/javax/swing/JRootPane.java	2011-01-20 23:54:21.000000000 +0000
|+++ openjdk/jdk/src/share/classes/javax/swing/JRootPane.java	2011-02-16 00:36:10.762530115 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/javax/swing/JRootPane.java using Plan A...
Hunk #1 succeeded at 34.
Hunk #2 succeeded at 689.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/classes/sun/awt/AWTAccessor.java openjdk/jdk/src/share/classes/sun/awt/AWTAccessor.java
|--- openjdk.orig/jdk/src/share/classes/sun/awt/AWTAccessor.java	2011-02-16 00:32:37.000000000 +0000
|+++ openjdk/jdk/src/share/classes/sun/awt/AWTAccessor.java	2011-02-16 00:37:57.566269674 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/awt/AWTAccessor.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 59.
Hunk #3 succeeded at 98.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/classes/sun/awt/SunToolkit.java openjdk/jdk/src/share/classes/sun/awt/SunToolkit.java
|--- openjdk.orig/jdk/src/share/classes/sun/awt/SunToolkit.java	2011-01-20 23:54:24.000000000 +0000
|+++ openjdk/jdk/src/share/classes/sun/awt/SunToolkit.java	2011-02-16 00:36:10.762530115 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/awt/SunToolkit.java using Plan A...
Hunk #1 succeeded at 1972 (offset -1 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/classes/sun/java2d/pipe/Region.java openjdk/jdk/src/share/classes/sun/java2d/pipe/Region.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pipe/Region.java	2011-01-20 23:54:26.000000000 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/Region.java	2011-02-16 00:36:10.762530115 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/Region.java using Plan A...
Hunk #1 succeeded at 28.
Hunk #2 succeeded at 64.
Hunk #3 succeeded at 131.
Hunk #4 succeeded at 212.
Hunk #5 succeeded at 1231.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/XComponentPeer.java openjdk/jdk/src/solaris/classes/sun/awt/X11/XComponentPeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/XComponentPeer.java	2011-01-20 23:54:40.000000000 +0000
|+++ openjdk/jdk/src/solaris/classes/sun/awt/X11/XComponentPeer.java	2011-02-16 00:36:10.762530115 +0000
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/X11/XComponentPeer.java using Plan A...
Hunk #1 succeeded at 1536.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/xawt/XlibWrapper.c openjdk/jdk/src/solaris/native/sun/xawt/XlibWrapper.c
|--- openjdk.orig/jdk/src/solaris/native/sun/xawt/XlibWrapper.c	2011-01-20 23:54:43.000000000 +0000
|+++ openjdk/jdk/src/solaris/native/sun/xawt/XlibWrapper.c	2011-02-16 00:36:10.762530115 +0000
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/xawt/XlibWrapper.c using Plan A...
Hunk #1 succeeded at 1933.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/classes/sun/awt/windows/WComponentPeer.java openjdk/jdk/src/windows/classes/sun/awt/windows/WComponentPeer.java
|--- openjdk.orig/jdk/src/windows/classes/sun/awt/windows/WComponentPeer.java	2011-01-20 23:54:43.000000000 +0000
|+++ openjdk/jdk/src/windows/classes/sun/awt/windows/WComponentPeer.java	2011-02-16 00:36:10.762530115 +0000
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/awt/windows/WComponentPeer.java using Plan A...
Hunk #1 succeeded at 878.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/native/sun/windows/awt_Component.cpp openjdk/jdk/src/windows/native/sun/windows/awt_Component.cpp
|--- openjdk.orig/jdk/src/windows/native/sun/windows/awt_Component.cpp	2011-02-16 00:32:37.000000000 +0000
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_Component.cpp	2011-02-16 00:36:10.766529806 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_Component.cpp using Plan A...
Hunk #1 succeeded at 6321 (offset 6 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/test/java/awt/Mixing/HWDisappear.java openjdk/jdk/test/java/awt/Mixing/HWDisappear.java
|--- openjdk.orig/jdk/test/java/awt/Mixing/HWDisappear.java	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/test/java/awt/Mixing/HWDisappear.java	2011-02-16 00:36:10.766529806 +0000
--------------------------
(Creating file openjdk/jdk/test/java/awt/Mixing/HWDisappear.java...)
Patching file openjdk/jdk/test/java/awt/Mixing/HWDisappear.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/test/java/awt/Mixing/JButtonInGlassPane.java openjdk/jdk/test/java/awt/Mixing/JButtonInGlassPane.java
|--- openjdk.orig/jdk/test/java/awt/Mixing/JButtonInGlassPane.java	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/test/java/awt/Mixing/JButtonInGlassPane.java	2011-02-16 00:36:10.766529806 +0000
--------------------------
(Creating file openjdk/jdk/test/java/awt/Mixing/JButtonInGlassPane.java...)
Patching file openjdk/jdk/test/java/awt/Mixing/JButtonInGlassPane.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/test/java/awt/Mixing/LWComboBox.java openjdk/jdk/test/java/awt/Mixing/LWComboBox.java
|--- openjdk.orig/jdk/test/java/awt/Mixing/LWComboBox.java	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/test/java/awt/Mixing/LWComboBox.java	2011-02-16 00:36:10.766529806 +0000
--------------------------
(Creating file openjdk/jdk/test/java/awt/Mixing/LWComboBox.java...)
Patching file openjdk/jdk/test/java/awt/Mixing/LWComboBox.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/test/java/awt/Mixing/MixingOnShrinkingHWButton.java openjdk/jdk/test/java/awt/Mixing/MixingOnShrinkingHWButton.java
|--- openjdk.orig/jdk/test/java/awt/Mixing/MixingOnShrinkingHWButton.java	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/test/java/awt/Mixing/MixingOnShrinkingHWButton.java	2011-02-16 00:36:10.766529806 +0000
--------------------------
(Creating file openjdk/jdk/test/java/awt/Mixing/MixingOnShrinkingHWButton.java...)
Patching file openjdk/jdk/test/java/awt/Mixing/MixingOnShrinkingHWButton.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/test/java/awt/Mixing/NonOpaqueInternalFrame.java openjdk/jdk/test/java/awt/Mixing/NonOpaqueInternalFrame.java
|--- openjdk.orig/jdk/test/java/awt/Mixing/NonOpaqueInternalFrame.java	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/test/java/awt/Mixing/NonOpaqueInternalFrame.java	2011-02-16 00:36:10.766529806 +0000
--------------------------
(Creating file openjdk/jdk/test/java/awt/Mixing/NonOpaqueInternalFrame.java...)
Patching file openjdk/jdk/test/java/awt/Mixing/NonOpaqueInternalFrame.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/test/java/awt/Mixing/OpaqueTest.java openjdk/jdk/test/java/awt/Mixing/OpaqueTest.java
|--- openjdk.orig/jdk/test/java/awt/Mixing/OpaqueTest.java	2011-01-20 23:54:46.000000000 +0000
|+++ openjdk/jdk/test/java/awt/Mixing/OpaqueTest.java	2011-02-16 00:36:10.766529806 +0000
--------------------------
Patching file openjdk/jdk/test/java/awt/Mixing/OpaqueTest.java using Plan A...
Hunk #1 succeeded at 42.
Hunk #2 succeeded at 79.
Hunk #3 succeeded at 89.
Hunk #4 succeeded at 123.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/test/java/awt/Mixing/OverlappingButtons.java openjdk/jdk/test/java/awt/Mixing/OverlappingButtons.java
|--- openjdk.orig/jdk/test/java/awt/Mixing/OverlappingButtons.java	2011-01-20 23:54:46.000000000 +0000
|+++ openjdk/jdk/test/java/awt/Mixing/OverlappingButtons.java	2011-02-16 00:36:10.766529806 +0000
--------------------------
Patching file openjdk/jdk/test/java/awt/Mixing/OverlappingButtons.java using Plan A...
Hunk #1 succeeded at 78.
Hunk #2 succeeded at 88.
done
Checking patches/openjdk/6725214-direct3d-01.patch
Applying patches/openjdk/6725214-direct3d-01.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User tdv
|# Date 1296837169 0
|# Node ID 6cf33f955d7dec149ada9a7f2358c38a9d6a3330
|# Parent  f683aef5858502b989c2bc0714003ca49d83c242
|6725214: D3D: forward-port the new pipeline from 6u10
|Summary: Forward port of the new Direct3D 9 rendering pipeline from 6u10. Also includes fixes for 6690659 6689025 6658398 6596234.
|Reviewed-by: campbell, prr
|
|diff -r f683aef58585 -r 6cf33f955d7d make/common/shared/Platform.gmk
|--- openjdk/jdk/make/common/shared/Platform.gmk	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/make/common/shared/Platform.gmk	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/make/common/shared/Platform.gmk using Plan A...
Hunk #1 succeeded at 363 (offset -14 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d make/common/shared/Sanity.gmk
|--- openjdk/jdk/make/common/shared/Sanity.gmk	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/make/common/shared/Sanity.gmk	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/make/common/shared/Sanity.gmk using Plan A...
Hunk #1 succeeded at 86 (offset -6 lines).
Hunk #2 succeeded at 1244 (offset -12 lines).
Hunk #3 succeeded at 1279 (offset -6 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d make/sun/awt/FILES_c_windows.gmk
|--- openjdk/jdk/make/sun/awt/FILES_c_windows.gmk	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/make/sun/awt/FILES_c_windows.gmk	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/make/sun/awt/FILES_c_windows.gmk using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 112.
Hunk #3 succeeded at 181.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d make/sun/awt/FILES_export_unix.gmk
|--- openjdk/jdk/make/sun/awt/FILES_export_unix.gmk	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/make/sun/awt/FILES_export_unix.gmk	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/make/sun/awt/FILES_export_unix.gmk using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 49.
Hunk #3 succeeded at 110.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d make/sun/awt/FILES_export_windows.gmk
|--- openjdk/jdk/make/sun/awt/FILES_export_windows.gmk	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/make/sun/awt/FILES_export_windows.gmk	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/make/sun/awt/FILES_export_windows.gmk using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 125.
Hunk #3 succeeded at 214.
Hunk #4 succeeded at 227.
Hunk #5 succeeded at 236.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d make/sun/awt/Makefile
|--- openjdk/jdk/make/sun/awt/Makefile	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/make/sun/awt/Makefile	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/make/sun/awt/Makefile using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 69.
Hunk #3 succeeded at 479.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d make/sun/awt/make.depend
|--- openjdk/jdk/make/sun/awt/make.depend	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/make/sun/awt/make.depend	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/make/sun/awt/make.depend using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 14.
Hunk #3 succeeded at 170.
Hunk #4 succeeded at 224.
Hunk #5 succeeded at 240.
Hunk #6 succeeded at 264.
Hunk #7 succeeded at 282.
Hunk #8 succeeded at 348.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d make/sun/awt/mapfile-mawt-vers
|--- openjdk/jdk/make/sun/awt/mapfile-mawt-vers	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/make/sun/awt/mapfile-mawt-vers	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/make/sun/awt/mapfile-mawt-vers using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 417.
Hunk #3 succeeded at 513.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d make/sun/awt/mapfile-vers
|--- openjdk/jdk/make/sun/awt/mapfile-vers	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/make/sun/awt/mapfile-vers	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/make/sun/awt/mapfile-vers using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 136.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d make/sun/awt/mapfile-vers-linux
|--- openjdk/jdk/make/sun/awt/mapfile-vers-linux	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/make/sun/awt/mapfile-vers-linux	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/make/sun/awt/mapfile-vers-linux using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 567.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d make/sun/font/FILES_c.gmk
|--- openjdk/jdk/make/sun/font/FILES_c.gmk	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/make/sun/font/FILES_c.gmk	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/make/sun/font/FILES_c.gmk using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 114.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d make/sun/font/Makefile
|--- openjdk/jdk/make/sun/font/Makefile	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/make/sun/font/Makefile	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/make/sun/font/Makefile using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 84.
Hunk #3 succeeded at 168.
Hunk #4 succeeded at 202.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d make/sun/headless/mapfile-vers
|--- openjdk/jdk/make/sun/headless/mapfile-vers	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/make/sun/headless/mapfile-vers	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/make/sun/headless/mapfile-vers using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 98.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d make/sun/jawt/make.depend
|--- openjdk/jdk/make/sun/jawt/make.depend	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/make/sun/jawt/make.depend	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/make/sun/jawt/make.depend using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d make/sun/xawt/mapfile-vers
|--- openjdk/jdk/make/sun/xawt/mapfile-vers	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/make/sun/xawt/mapfile-vers	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/make/sun/xawt/mapfile-vers using Plan A...
Hunk #1 succeeded at 242.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/java/awt/Component.java
|--- openjdk/jdk/src/share/classes/java/awt/Component.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/classes/java/awt/Component.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/Component.java using Plan A...
Hunk #1 succeeded at 77 (offset 2 lines).
Hunk #2 succeeded at 3582 (offset 26 lines).
Hunk #3 succeeded at 3573 (offset 2 lines).
Hunk #4 succeeded at 3744 (offset 26 lines).
Hunk #5 succeeded at 3788 (offset 2 lines).
Hunk #6 succeeded at 3839 (offset 26 lines).
Hunk #7 succeeded at 3828 (offset 2 lines).
Hunk #8 succeeded at 3944 (offset 26 lines).
Hunk #9 succeeded at 4197 (offset 2 lines).
Hunk #10 succeeded at 4234 (offset 26 lines).
Hunk #11 succeeded at 4244 (offset 2 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/java/awt/GraphicsDevice.java
|--- openjdk/jdk/src/share/classes/java/awt/GraphicsDevice.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/classes/java/awt/GraphicsDevice.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/GraphicsDevice.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 236.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/java/awt/Robot.java
|--- openjdk/jdk/src/share/classes/java/awt/Robot.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/classes/java/awt/Robot.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/Robot.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 25.
Hunk #3 succeeded at 341.
Hunk #4 succeeded at 356.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/java/awt/image/DataBuffer.java
|--- openjdk/jdk/src/share/classes/java/awt/image/DataBuffer.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/classes/java/awt/image/DataBuffer.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/image/DataBuffer.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 530.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/java/awt/peer/ComponentPeer.java
|--- openjdk/jdk/src/share/classes/java/awt/peer/ComponentPeer.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/classes/java/awt/peer/ComponentPeer.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/peer/ComponentPeer.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 88.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/javax/swing/BufferStrategyPaintManager.java
|--- openjdk/jdk/src/share/classes/javax/swing/BufferStrategyPaintManager.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/classes/javax/swing/BufferStrategyPaintManager.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/javax/swing/BufferStrategyPaintManager.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 263.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/awt/NullComponentPeer.java
|--- openjdk/jdk/src/share/classes/sun/awt/NullComponentPeer.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/classes/sun/awt/NullComponentPeer.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/awt/NullComponentPeer.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 255.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/awt/SubRegionShowable.java
|--- openjdk/jdk/src/share/classes/sun/awt/SubRegionShowable.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/classes/sun/awt/SubRegionShowable.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/awt/SubRegionShowable.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 39.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/awt/image/SunVolatileImage.java
|--- openjdk/jdk/src/share/classes/sun/awt/image/SunVolatileImage.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/classes/sun/awt/image/SunVolatileImage.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/awt/image/SunVolatileImage.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 29.
Hunk #3 succeeded at 51.
Hunk #4 succeeded at 96.
Hunk #5 succeeded at 114.
Hunk #6 succeeded at 149.
Hunk #7 succeeded at 256.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/awt/image/SunWritableRaster.java
|--- openjdk/jdk/src/share/classes/sun/awt/image/SunWritableRaster.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/classes/sun/awt/image/SunWritableRaster.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/awt/image/SunWritableRaster.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 35.
Hunk #3 succeeded at 55.
Hunk #4 succeeded at 81.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/awt/image/VSyncedBSManager.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/share/classes/sun/awt/image/VSyncedBSManager.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/share/classes/sun/awt/image/VSyncedBSManager.java...)
Patching file openjdk/jdk/src/share/classes/sun/awt/image/VSyncedBSManager.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/awt/image/VolatileSurfaceManager.java
|--- openjdk/jdk/src/share/classes/sun/awt/image/VolatileSurfaceManager.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/classes/sun/awt/image/VolatileSurfaceManager.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/awt/image/VolatileSurfaceManager.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 37.
Hunk #3 succeeded at 118.
Hunk #4 succeeded at 275.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/font/StrikeCache.java
|--- openjdk/jdk/src/share/classes/sun/font/StrikeCache.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/classes/sun/font/StrikeCache.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/font/StrikeCache.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 25.
Hunk #3 succeeded at 193.
Hunk #4 succeeded at 208.
Hunk #5 succeeded at 224.
Hunk #6 succeeded at 235.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/java2d/DestSurfaceProvider.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/DestSurfaceProvider.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/share/classes/sun/java2d/DestSurfaceProvider.java...)
Patching file openjdk/jdk/src/share/classes/sun/java2d/DestSurfaceProvider.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/java2d/SunGraphics2D.java
|--- openjdk/jdk/src/share/classes/sun/java2d/SunGraphics2D.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/SunGraphics2D.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/SunGraphics2D.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 41.
Hunk #3 succeeded at 62.
Hunk #4 succeeded at 80.
Hunk #5 succeeded at 88.
Hunk #6 succeeded at 102.
Hunk #7 succeeded at 3277.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/java2d/SunGraphicsEnvironment.java
|--- openjdk/jdk/src/share/classes/sun/java2d/SunGraphicsEnvironment.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/SunGraphicsEnvironment.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/SunGraphicsEnvironment.java using Plan A...
Hunk #1 succeeded at 36.
Hunk #2 succeeded at 1277.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/java2d/Surface.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/Surface.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/share/classes/sun/java2d/Surface.java...)
Patching file openjdk/jdk/src/share/classes/sun/java2d/Surface.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/java2d/SurfaceData.java
|--- openjdk/jdk/src/share/classes/sun/java2d/SurfaceData.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/SurfaceData.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/SurfaceData.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 93.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/java2d/SurfaceDataProxy.java
|--- openjdk/jdk/src/share/classes/sun/java2d/SurfaceDataProxy.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/SurfaceDataProxy.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/SurfaceDataProxy.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 521.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/java2d/loops/BlitBg.java
|--- openjdk/jdk/src/share/classes/sun/java2d/loops/BlitBg.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/loops/BlitBg.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/loops/BlitBg.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 109.
Hunk #3 succeeded at 142.
Hunk #4 succeeded at 163.
Hunk #5 succeeded at 202.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/java2d/loops/GeneralRenderer.java
|--- openjdk/jdk/src/share/classes/sun/java2d/loops/GeneralRenderer.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/loops/GeneralRenderer.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/loops/GeneralRenderer.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 159.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/java2d/opengl/OGLBufImgOps.java
|--- openjdk/jdk/src/share/classes/sun/java2d/opengl/OGLBufImgOps.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/opengl/OGLBufImgOps.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/opengl/OGLBufImgOps.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 35.
Hunk #3 succeeded at 95.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/java2d/opengl/OGLContext.java
|--- openjdk/jdk/src/share/classes/sun/java2d/opengl/OGLContext.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/opengl/OGLContext.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/opengl/OGLContext.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 25.
Hunk #3 succeeded at 93.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/java2d/opengl/OGLGraphicsConfig.java
|--- openjdk/jdk/src/share/classes/sun/java2d/opengl/OGLGraphicsConfig.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/opengl/OGLGraphicsConfig.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/opengl/OGLGraphicsConfig.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 27.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/java2d/opengl/OGLPaints.java
|--- openjdk/jdk/src/share/classes/sun/java2d/opengl/OGLPaints.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/opengl/OGLPaints.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/opengl/OGLPaints.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 39.
Hunk #3 succeeded at 171.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/java2d/opengl/OGLRenderer.java
|--- openjdk/jdk/src/share/classes/sun/java2d/opengl/OGLRenderer.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/opengl/OGLRenderer.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/opengl/OGLRenderer.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 30.
Hunk #3 succeeded at 52.
Hunk #4 succeeded at 98.
Hunk #5 succeeded at 165.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/java2d/opengl/OGLSurfaceData.java
|--- openjdk/jdk/src/share/classes/sun/java2d/opengl/OGLSurfaceData.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/opengl/OGLSurfaceData.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/opengl/OGLSurfaceData.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 27.
Hunk #3 succeeded at 95.
Hunk #4 succeeded at 150.
Hunk #5 succeeded at 175.
Hunk #6 succeeded at 209.
Hunk #7 succeeded at 293.
Hunk #8 succeeded at 332.
Hunk #9 succeeded at 346.
Hunk #10 succeeded at 355.
Hunk #11 succeeded at 408.
Hunk #12 succeeded at 447.
Hunk #13 succeeded at 464.
Hunk #14 succeeded at 501.
Hunk #15 succeeded at 534.
Hunk #16 succeeded at 626.
Hunk #17 succeeded at 635.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/java2d/pipe/BufferedContext.java
|--- openjdk/jdk/src/share/classes/sun/java2d/pipe/BufferedContext.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/BufferedContext.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/BufferedContext.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 26.
Hunk #3 succeeded at 44.
Hunk #4 succeeded at 85.
Hunk #5 succeeded at 103.
Hunk #6 succeeded at 156.
Hunk #7 succeeded at 225.
Hunk #8 succeeded at 260.
Hunk #9 succeeded at 296.
Hunk #10 succeeded at 304.
Hunk #11 succeeded at 414.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/java2d/pipe/BufferedOpCodes.java
|--- openjdk/jdk/src/share/classes/sun/java2d/pipe/BufferedOpCodes.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/BufferedOpCodes.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/BufferedOpCodes.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 32.
Hunk #3 succeeded at 71.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/java2d/pipe/BufferedRenderPipe.java
|--- openjdk/jdk/src/share/classes/sun/java2d/pipe/BufferedRenderPipe.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/BufferedRenderPipe.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/BufferedRenderPipe.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 25.
Hunk #3 succeeded at 34.
Hunk #4 succeeded at 53.
Hunk #5 succeeded at 71.
Hunk #6 succeeded at 407.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/java2d/pipe/DrawImage.java
|--- openjdk/jdk/src/share/classes/sun/java2d/pipe/DrawImage.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/DrawImage.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/DrawImage.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 958 (offset 3 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/java2d/pipe/ParallelogramPipe.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/ParallelogramPipe.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/share/classes/sun/java2d/pipe/ParallelogramPipe.java...)
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/ParallelogramPipe.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/java2d/pipe/PixelToParallelogramConverter.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/PixelToParallelogramConverter.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/share/classes/sun/java2d/pipe/PixelToParallelogramConverter.java...)
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/PixelToParallelogramConverter.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/java2d/pipe/hw/AccelDeviceEventListener.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/hw/AccelDeviceEventListener.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/share/classes/sun/java2d/pipe/hw/AccelDeviceEventListener.java...)
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/hw/AccelDeviceEventListener.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/java2d/pipe/hw/AccelDeviceEventNotifier.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/hw/AccelDeviceEventNotifier.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/share/classes/sun/java2d/pipe/hw/AccelDeviceEventNotifier.java...)
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/hw/AccelDeviceEventNotifier.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/java2d/pipe/hw/AccelGraphicsConfig.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/hw/AccelGraphicsConfig.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/share/classes/sun/java2d/pipe/hw/AccelGraphicsConfig.java...)
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/hw/AccelGraphicsConfig.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/java2d/pipe/hw/AccelSurface.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/hw/AccelSurface.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/share/classes/sun/java2d/pipe/hw/AccelSurface.java...)
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/hw/AccelSurface.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/java2d/pipe/hw/AccelTypedVolatileImage.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/hw/AccelTypedVolatileImage.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/share/classes/sun/java2d/pipe/hw/AccelTypedVolatileImage.java...)
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/hw/AccelTypedVolatileImage.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/java2d/pipe/hw/BufferedContextProvider.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/hw/BufferedContextProvider.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/share/classes/sun/java2d/pipe/hw/BufferedContextProvider.java...)
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/hw/BufferedContextProvider.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/java2d/pipe/hw/ContextCapabilities.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/hw/ContextCapabilities.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/share/classes/sun/java2d/pipe/hw/ContextCapabilities.java...)
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/hw/ContextCapabilities.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/classes/sun/java2d/pipe/hw/ExtendedBufferCapabilities.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/hw/ExtendedBufferCapabilities.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/share/classes/sun/java2d/pipe/hw/ExtendedBufferCapabilities.java...)
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/hw/ExtendedBufferCapabilities.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/native/sun/font/AccelGlyphCache.c
|--- openjdk/jdk/src/share/native/sun/font/AccelGlyphCache.c	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/native/sun/font/AccelGlyphCache.c	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/native/sun/font/AccelGlyphCache.c using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 45.
Hunk #3 succeeded at 99.
Hunk #4 succeeded at 115.
Hunk #5 succeeded at 142.
Hunk #6 succeeded at 151.
Hunk #7 succeeded at 169.
Hunk #8 succeeded at 228.
Hunk #9 succeeded at 239.
Hunk #10 succeeded at 270.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/native/sun/font/AccelGlyphCache.h
|--- openjdk/jdk/src/share/native/sun/font/AccelGlyphCache.h	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/native/sun/font/AccelGlyphCache.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/native/sun/font/AccelGlyphCache.h using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 26.
Hunk #3 succeeded at 52.
Hunk #4 succeeded at 74.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/native/sun/font/sunFont.c
|--- openjdk/jdk/src/share/native/sun/font/sunFont.c	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/native/sun/font/sunFont.c	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/native/sun/font/sunFont.c using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 35.
Hunk #3 succeeded at 296.
Hunk #4 succeeded at 326.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/native/sun/java2d/ShaderList.c
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/share/native/sun/java2d/ShaderList.c	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/share/native/sun/java2d/ShaderList.c...)
Patching file openjdk/jdk/src/share/native/sun/java2d/ShaderList.c using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/native/sun/java2d/ShaderList.h
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/share/native/sun/java2d/ShaderList.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/share/native/sun/java2d/ShaderList.h...)
Patching file openjdk/jdk/src/share/native/sun/java2d/ShaderList.h using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/native/sun/java2d/Trace.h
|--- openjdk/jdk/src/share/native/sun/java2d/Trace.h	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/native/sun/java2d/Trace.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/native/sun/java2d/Trace.h using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 62.
Hunk #3 succeeded at 93.
Hunk #4 succeeded at 120.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/native/sun/java2d/loops/BlitBg.c
|--- openjdk/jdk/src/share/native/sun/java2d/loops/BlitBg.c	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/native/sun/java2d/loops/BlitBg.c	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/native/sun/java2d/loops/BlitBg.c using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 31.
Hunk #3 succeeded at 93.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.c
|--- openjdk/jdk/src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.c	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.c	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.c using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 50.
Hunk #3 succeeded at 63.
Hunk #4 succeeded at 115.
Hunk #5 succeeded at 139.
Hunk #6 succeeded at 467.
Hunk #7 succeeded at 492.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.h
|--- openjdk/jdk/src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.h	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.h using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 501.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/native/sun/java2d/opengl/OGLContext.c
|--- openjdk/jdk/src/share/native/sun/java2d/opengl/OGLContext.c	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/native/sun/java2d/opengl/OGLContext.c	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/native/sun/java2d/opengl/OGLContext.c using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 852.
Hunk #3 succeeded at 913.
Hunk #4 succeeded at 1015.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/native/sun/java2d/opengl/OGLContext.h
|--- openjdk/jdk/src/share/native/sun/java2d/opengl/OGLContext.h	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/native/sun/java2d/opengl/OGLContext.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/native/sun/java2d/opengl/OGLContext.h using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 28.
Hunk #3 succeeded at 97.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/native/sun/java2d/opengl/OGLFuncs.h
|--- openjdk/jdk/src/share/native/sun/java2d/opengl/OGLFuncs.h	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/native/sun/java2d/opengl/OGLFuncs.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/native/sun/java2d/opengl/OGLFuncs.h using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 91.
Hunk #3 succeeded at 159.
Hunk #4 succeeded at 249.
Hunk #5 succeeded at 308.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/native/sun/java2d/opengl/OGLRenderQueue.c
|--- openjdk/jdk/src/share/native/sun/java2d/opengl/OGLRenderQueue.c	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/native/sun/java2d/opengl/OGLRenderQueue.c	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/native/sun/java2d/opengl/OGLRenderQueue.c using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 88.
Hunk #3 succeeded at 149.
Hunk #4 succeeded at 201.
Hunk #5 succeeded at 501.
Hunk #6 succeeded at 779.
Hunk #7 succeeded at 809.
Hunk #8 succeeded at 839.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/native/sun/java2d/opengl/OGLRenderQueue.h
|--- openjdk/jdk/src/share/native/sun/java2d/opengl/OGLRenderQueue.h	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/native/sun/java2d/opengl/OGLRenderQueue.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/native/sun/java2d/opengl/OGLRenderQueue.h using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 90.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/native/sun/java2d/opengl/OGLRenderer.c
|--- openjdk/jdk/src/share/native/sun/java2d/opengl/OGLRenderer.c	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/native/sun/java2d/opengl/OGLRenderer.c	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/native/sun/java2d/opengl/OGLRenderer.c using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 27.
Hunk #3 succeeded at 327.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/native/sun/java2d/opengl/OGLRenderer.h
|--- openjdk/jdk/src/share/native/sun/java2d/opengl/OGLRenderer.h	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/native/sun/java2d/opengl/OGLRenderer.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/native/sun/java2d/opengl/OGLRenderer.h using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 46.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/native/sun/java2d/opengl/OGLSurfaceData.c
|--- openjdk/jdk/src/share/native/sun/java2d/opengl/OGLSurfaceData.c	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/native/sun/java2d/opengl/OGLSurfaceData.c	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/native/sun/java2d/opengl/OGLSurfaceData.c using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 41.
Hunk #3 succeeded at 271.
Hunk #4 succeeded at 432.
Hunk #5 succeeded at 484.
Hunk #6 succeeded at 507.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/native/sun/java2d/opengl/OGLSurfaceData.h
|--- openjdk/jdk/src/share/native/sun/java2d/opengl/OGLSurfaceData.h	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/native/sun/java2d/opengl/OGLSurfaceData.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/native/sun/java2d/opengl/OGLSurfaceData.h using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 28.
Hunk #3 succeeded at 216.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/share/native/sun/java2d/pipe/BufferedMaskBlit.c
|--- openjdk/jdk/src/share/native/sun/java2d/pipe/BufferedMaskBlit.c	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/share/native/sun/java2d/pipe/BufferedMaskBlit.c	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/share/native/sun/java2d/pipe/BufferedMaskBlit.c using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 59.
Hunk #3 succeeded at 96.
Hunk #4 succeeded at 104.
Hunk #5 succeeded at 119.
Hunk #6 succeeded at 165.
Hunk #7 succeeded at 194.
Hunk #8 succeeded at 219.
Hunk #9 succeeded at 245.
Hunk #10 succeeded at 272.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/solaris/classes/sun/awt/X11/XComponentPeer.java
|--- openjdk/jdk/src/solaris/classes/sun/awt/X11/XComponentPeer.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/solaris/classes/sun/awt/X11/XComponentPeer.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/X11/XComponentPeer.java using Plan A...
Hunk #1 succeeded at 77.
Hunk #2 succeeded at 1289.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/solaris/classes/sun/awt/X11/XEmbedChildProxyPeer.java
|--- openjdk/jdk/src/solaris/classes/sun/awt/X11/XEmbedChildProxyPeer.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/solaris/classes/sun/awt/X11/XEmbedChildProxyPeer.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/X11/XEmbedChildProxyPeer.java using Plan A...
Hunk #1 succeeded at 257.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/solaris/classes/sun/awt/X11GraphicsConfig.java
|--- openjdk/jdk/src/solaris/classes/sun/awt/X11GraphicsConfig.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/solaris/classes/sun/awt/X11GraphicsConfig.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/X11GraphicsConfig.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 27.
Hunk #3 succeeded at 434.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/solaris/classes/sun/awt/X11GraphicsDevice.java
|--- openjdk/jdk/src/solaris/classes/sun/awt/X11GraphicsDevice.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/solaris/classes/sun/awt/X11GraphicsDevice.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/X11GraphicsDevice.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 385.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/solaris/classes/sun/java2d/BackBufferCapsProvider.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/solaris/classes/sun/java2d/BackBufferCapsProvider.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/solaris/classes/sun/java2d/BackBufferCapsProvider.java...)
Patching file openjdk/jdk/src/solaris/classes/sun/java2d/BackBufferCapsProvider.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/solaris/classes/sun/java2d/opengl/GLXGraphicsConfig.java
|--- openjdk/jdk/src/solaris/classes/sun/java2d/opengl/GLXGraphicsConfig.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/solaris/classes/sun/java2d/opengl/GLXGraphicsConfig.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/java2d/opengl/GLXGraphicsConfig.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 27.
Hunk #3 succeeded at 48.
Hunk #4 succeeded at 69.
Hunk #5 succeeded at 77.
Hunk #6 succeeded at 108.
Hunk #7 succeeded at 120.
Hunk #8 succeeded at 134.
Hunk #9 succeeded at 163.
Hunk #10 succeeded at 308.
Hunk #11 succeeded at 386.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/solaris/classes/sun/java2d/opengl/GLXSurfaceData.java
|--- openjdk/jdk/src/solaris/classes/sun/java2d/opengl/GLXSurfaceData.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/solaris/classes/sun/java2d/opengl/GLXSurfaceData.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/java2d/opengl/GLXSurfaceData.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 73.
Hunk #3 succeeded at 141.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/solaris/classes/sun/java2d/opengl/GLXVolatileSurfaceManager.java
|--- openjdk/jdk/src/solaris/classes/sun/java2d/opengl/GLXVolatileSurfaceManager.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/solaris/classes/sun/java2d/opengl/GLXVolatileSurfaceManager.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/java2d/opengl/GLXVolatileSurfaceManager.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 25.
Hunk #3 succeeded at 61.
Hunk #4 succeeded at 80.
Hunk #5 succeeded at 133.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/solaris/classes/sun/java2d/x11/X11PMBlitBgLoops.java
|--- openjdk/jdk/src/solaris/classes/sun/java2d/x11/X11PMBlitBgLoops.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/solaris/classes/sun/java2d/x11/X11PMBlitBgLoops.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/java2d/x11/X11PMBlitBgLoops.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 79.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/solaris/native/sun/java2d/opengl/GLXGraphicsConfig.c
|--- openjdk/jdk/src/solaris/native/sun/java2d/opengl/GLXGraphicsConfig.c	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/solaris/native/sun/java2d/opengl/GLXGraphicsConfig.c	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/java2d/opengl/GLXGraphicsConfig.c using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 471.
Hunk #3 succeeded at 581.
Hunk #4 succeeded at 662.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c
|--- openjdk/jdk/src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 47.
Hunk #3 succeeded at 463.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/awt/Win32GraphicsConfig.java
|--- openjdk/jdk/src/windows/classes/sun/awt/Win32GraphicsConfig.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/classes/sun/awt/Win32GraphicsConfig.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/awt/Win32GraphicsConfig.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 55.
Hunk #3 succeeded at 70.
Hunk #4 succeeded at 174.
Hunk #5 succeeded at 230.
Hunk #6 succeeded at 251.
Hunk #7 succeeded at 273.
Hunk #8 succeeded at 282.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/awt/Win32GraphicsDevice.java
|--- openjdk/jdk/src/windows/classes/sun/awt/Win32GraphicsDevice.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/classes/sun/awt/Win32GraphicsDevice.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/awt/Win32GraphicsDevice.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 33.
Hunk #3 succeeded at 56.
Hunk #4 succeeded at 69.
Hunk #5 succeeded at 95.
Hunk #6 succeeded at 103.
Hunk #7 succeeded at 131.
Hunk #8 succeeded at 140.
Hunk #9 succeeded at 173.
Hunk #10 succeeded at 303.
Hunk #11 succeeded at 320.
Hunk #12 succeeded at 353.
Hunk #13 succeeded at 388.
Hunk #14 succeeded at 429.
Hunk #15 succeeded at 453.
Hunk #16 succeeded at 477.
Hunk #17 succeeded at 534.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/awt/Win32GraphicsEnvironment.java
|--- openjdk/jdk/src/windows/classes/sun/awt/Win32GraphicsEnvironment.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/classes/sun/awt/Win32GraphicsEnvironment.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/awt/Win32GraphicsEnvironment.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 25.
Hunk #3 succeeded at 44.
Hunk #4 succeeded at 324.
Hunk #5 succeeded at 344.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/awt/windows/WComponentPeer.java
|--- openjdk/jdk/src/windows/classes/sun/awt/windows/WComponentPeer.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/classes/sun/awt/windows/WComponentPeer.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/awt/windows/WComponentPeer.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 40.
Hunk #3 succeeded at 53.
Hunk #4 succeeded at 88.
Hunk #5 succeeded at 193.
Hunk #6 succeeded at 381.
Hunk #7 succeeded at 390.
Hunk #8 succeeded at 538.
Hunk #9 succeeded at 553.
Hunk #10 succeeded at 570.
Hunk #11 succeeded at 651.
Hunk #12 succeeded at 828.
Hunk #13 succeeded at 838.
Hunk #14 succeeded at 907.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/awt/windows/WEmbeddedFramePeer.java
|--- openjdk/jdk/src/windows/classes/sun/awt/windows/WEmbeddedFramePeer.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/classes/sun/awt/windows/WEmbeddedFramePeer.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/awt/windows/WEmbeddedFramePeer.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 30.
Hunk #3 succeeded at 72.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/awt/windows/WToolkit.java
|--- openjdk/jdk/src/windows/classes/sun/awt/windows/WToolkit.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/classes/sun/awt/windows/WToolkit.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/awt/windows/WToolkit.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 40.
Hunk #3 succeeded at 596.
Hunk #4 succeeded at 917.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/ScreenUpdateManager.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/classes/sun/java2d/ScreenUpdateManager.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/classes/sun/java2d/ScreenUpdateManager.java...)
Patching file openjdk/jdk/src/windows/classes/sun/java2d/ScreenUpdateManager.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/SurfaceManagerFactory.java
|--- openjdk/jdk/src/windows/classes/sun/java2d/SurfaceManagerFactory.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/classes/sun/java2d/SurfaceManagerFactory.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/java2d/SurfaceManagerFactory.java using Plan A...
Hunk #1 succeeded at 26.
Hunk #2 succeeded at 54.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/d3d/D3DBackBufferSurfaceData.java
|--- openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DBackBufferSurfaceData.java	Tue Feb 01 19:38:05 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DBackBufferSurfaceData.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/d3d/D3DBlitLoops.java
|--- openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DBlitLoops.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DBlitLoops.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DBlitLoops.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 29.
Hunk #3 succeeded at 808.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/d3d/D3DBufImgOps.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DBufImgOps.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DBufImgOps.java...)
Patching file openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DBufImgOps.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/d3d/D3DContext.java
|--- openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DContext.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DContext.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DContext.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 25.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/d3d/D3DDrawImage.java
|--- openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DDrawImage.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DDrawImage.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DDrawImage.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 29.
Hunk #3 succeeded at 38.
Hunk #4 succeeded at 48.
Hunk #5 succeeded at 57.
Hunk #6 succeeded at 77.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/d3d/D3DGraphicsConfig.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DGraphicsConfig.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DGraphicsConfig.java...)
Patching file openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DGraphicsConfig.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/d3d/D3DGraphicsDevice.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DGraphicsDevice.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DGraphicsDevice.java...)
Patching file openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DGraphicsDevice.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/d3d/D3DMaskBlit.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DMaskBlit.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DMaskBlit.java...)
Patching file openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DMaskBlit.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/d3d/D3DMaskFill.java
|--- openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DMaskFill.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DMaskFill.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DMaskFill.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 25.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/d3d/D3DPaints.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DPaints.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DPaints.java...)
Patching file openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DPaints.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/d3d/D3DRenderQueue.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DRenderQueue.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DRenderQueue.java...)
Patching file openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DRenderQueue.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/d3d/D3DRenderer.java
|--- openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DRenderer.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DRenderer.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DRenderer.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 25.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/d3d/D3DScreenUpdateManager.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DScreenUpdateManager.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DScreenUpdateManager.java...)
Patching file openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DScreenUpdateManager.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java
|--- openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 26.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/d3d/D3DSurfaceDataProxy.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DSurfaceDataProxy.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DSurfaceDataProxy.java...)
Patching file openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DSurfaceDataProxy.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/d3d/D3DTextRenderer.java
|--- openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DTextRenderer.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DTextRenderer.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DTextRenderer.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 25.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/d3d/D3DVolatileSurfaceManager.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DVolatileSurfaceManager.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DVolatileSurfaceManager.java...)
Patching file openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DVolatileSurfaceManager.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/opengl/WGLGraphicsConfig.java
|--- openjdk/jdk/src/windows/classes/sun/java2d/opengl/WGLGraphicsConfig.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/classes/sun/java2d/opengl/WGLGraphicsConfig.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/java2d/opengl/WGLGraphicsConfig.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 27.
Hunk #3 succeeded at 42.
Hunk #4 succeeded at 68.
Hunk #5 succeeded at 82.
Hunk #6 succeeded at 115.
Hunk #7 succeeded at 127.
Hunk #8 succeeded at 141.
Hunk #9 succeeded at 174.
Hunk #10 succeeded at 279.
Hunk #11 succeeded at 332.
Hunk #12 succeeded at 392.
Hunk #13 succeeded at 411.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/opengl/WGLSurfaceData.java
|--- openjdk/jdk/src/windows/classes/sun/java2d/opengl/WGLSurfaceData.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/classes/sun/java2d/opengl/WGLSurfaceData.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/java2d/opengl/WGLSurfaceData.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 26.
Hunk #3 succeeded at 55.
Hunk #4 succeeded at 69.
Hunk #5 succeeded at 87.
Hunk #6 succeeded at 164.
Hunk #7 succeeded at 241.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/opengl/WGLVolatileSurfaceManager.java
|--- openjdk/jdk/src/windows/classes/sun/java2d/opengl/WGLVolatileSurfaceManager.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/classes/sun/java2d/opengl/WGLVolatileSurfaceManager.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/java2d/opengl/WGLVolatileSurfaceManager.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 25.
Hunk #3 succeeded at 61.
Hunk #4 succeeded at 80.
Hunk #5 succeeded at 131.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/windows/DDBlitLoops.java
|--- openjdk/jdk/src/windows/classes/sun/java2d/windows/DDBlitLoops.java	Tue Feb 01 19:38:05 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/java2d/windows/DDBlitLoops.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/windows/DDRenderer.java
|--- openjdk/jdk/src/windows/classes/sun/java2d/windows/DDRenderer.java	Tue Feb 01 19:38:05 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/java2d/windows/DDRenderer.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/windows/DDScaleLoops.java
|--- openjdk/jdk/src/windows/classes/sun/java2d/windows/DDScaleLoops.java	Tue Feb 01 19:38:05 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/java2d/windows/DDScaleLoops.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/windows/GDIBlitLoops.java
|--- openjdk/jdk/src/windows/classes/sun/java2d/windows/GDIBlitLoops.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/classes/sun/java2d/windows/GDIBlitLoops.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/java2d/windows/GDIBlitLoops.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 60.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/windows/GDIWindowSurfaceData.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/classes/sun/java2d/windows/GDIWindowSurfaceData.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/classes/sun/java2d/windows/GDIWindowSurfaceData.java...)
Patching file openjdk/jdk/src/windows/classes/sun/java2d/windows/GDIWindowSurfaceData.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/windows/Win32OffScreenSurfaceData.java
|--- openjdk/jdk/src/windows/classes/sun/java2d/windows/Win32OffScreenSurfaceData.java	Tue Feb 01 19:38:05 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/java2d/windows/Win32OffScreenSurfaceData.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/windows/Win32SurfaceData.java
|--- openjdk/jdk/src/windows/classes/sun/java2d/windows/Win32SurfaceData.java	Tue Feb 01 19:38:05 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/java2d/windows/Win32SurfaceData.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/windows/Win32SurfaceDataProxy.java
|--- openjdk/jdk/src/windows/classes/sun/java2d/windows/Win32SurfaceDataProxy.java	Tue Feb 01 19:38:05 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/java2d/windows/Win32SurfaceDataProxy.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/windows/WinBackBuffer.java
|--- openjdk/jdk/src/windows/classes/sun/java2d/windows/WinBackBuffer.java	Tue Feb 01 19:38:05 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/java2d/windows/WinBackBuffer.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/windows/WinBackBufferSurfaceData.java
|--- openjdk/jdk/src/windows/classes/sun/java2d/windows/WinBackBufferSurfaceData.java	Tue Feb 01 19:38:05 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/java2d/windows/WinBackBufferSurfaceData.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/windows/WinVolatileSurfaceManager.java
|--- openjdk/jdk/src/windows/classes/sun/java2d/windows/WinVolatileSurfaceManager.java	Tue Feb 01 19:38:05 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/java2d/windows/WinVolatileSurfaceManager.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/classes/sun/java2d/windows/WindowsFlags.java
|--- openjdk/jdk/src/windows/classes/sun/java2d/windows/WindowsFlags.java	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/classes/sun/java2d/windows/WindowsFlags.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/java2d/windows/WindowsFlags.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 39.
Hunk #3 succeeded at 67.
Hunk #4 succeeded at 113.
Hunk #5 succeeded at 206.
Hunk #6 succeeded at 233.
Hunk #7 succeeded at 251.
Hunk #8 succeeded at 269.
Hunk #9 succeeded at 296.
Hunk #10 succeeded at 304.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DBadHardware.h
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DBadHardware.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DBadHardware.h...)
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DBadHardware.h using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DBlitLoops.cpp
|--- openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DBlitLoops.cpp	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DBlitLoops.cpp	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DBlitLoops.cpp using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 23.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DBlitLoops.h
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DBlitLoops.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DBlitLoops.h...)
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DBlitLoops.h using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DBufImgOps.cpp
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DBufImgOps.cpp	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DBufImgOps.cpp...)
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DBufImgOps.cpp using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DBufImgOps.h
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DBufImgOps.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DBufImgOps.h...)
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DBufImgOps.h using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DContext.cpp
|--- openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DContext.cpp	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DContext.cpp	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DContext.cpp using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 23.
Hunk #3 succeeded at 63.
Hunk #4 succeeded at 972.
Hunk #5 succeeded at 1109.
Hunk #6 succeeded at 1492.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DContext.h
|--- openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DContext.h	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DContext.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DContext.h using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 27.
Hunk #3 succeeded at 71.
Hunk #4 succeeded at 100.
Hunk #5 succeeded at 108.
Hunk #6 succeeded at 124.
Hunk #7 succeeded at 279.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DGlyphCache.cpp
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DGlyphCache.cpp	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DGlyphCache.cpp...)
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DGlyphCache.cpp using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DGlyphCache.h
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DGlyphCache.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DGlyphCache.h...)
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DGlyphCache.h using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DGraphicsDevice.cpp
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DGraphicsDevice.cpp	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DGraphicsDevice.cpp...)
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DGraphicsDevice.cpp using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DGraphicsDevice.h
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DGraphicsDevice.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DGraphicsDevice.h...)
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DGraphicsDevice.h using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DMaskBlit.cpp
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DMaskBlit.cpp	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DMaskBlit.cpp...)
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DMaskBlit.cpp using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DMaskBlit.h
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DMaskBlit.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DMaskBlit.h...)
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DMaskBlit.h using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DMaskCache.cpp
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DMaskCache.cpp	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DMaskCache.cpp...)
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DMaskCache.cpp using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DMaskCache.h
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DMaskCache.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DMaskCache.h...)
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DMaskCache.h using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DMaskFill.cpp
|--- openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DMaskFill.cpp	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DMaskFill.cpp	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DMaskFill.cpp using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 23.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DMaskFill.h
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DMaskFill.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DMaskFill.h...)
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DMaskFill.h using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DPaints.cpp
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DPaints.cpp	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DPaints.cpp...)
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DPaints.cpp using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DPaints.h
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DPaints.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DPaints.h...)
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DPaints.h using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DPipeline.cpp
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DPipeline.cpp	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DPipeline.cpp...)
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DPipeline.cpp using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DPipeline.h
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DPipeline.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DPipeline.h...)
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DPipeline.h using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp...)
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DPipelineManager.h
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DPipelineManager.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DPipelineManager.h...)
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DPipelineManager.h using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DRenderQueue.cpp
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DRenderQueue.cpp	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DRenderQueue.cpp...)
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DRenderQueue.cpp using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DRenderQueue.h
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DRenderQueue.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DRenderQueue.h...)
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DRenderQueue.h using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DRenderer.cpp
|--- openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DRenderer.cpp	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DRenderer.cpp	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DRenderer.cpp using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 24.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DRenderer.h
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DRenderer.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DRenderer.h...)
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DRenderer.h using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DResourceManager.cpp
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DResourceManager.cpp	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DResourceManager.cpp...)
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DResourceManager.cpp using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DResourceManager.h
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DResourceManager.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DResourceManager.h...)
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DResourceManager.h using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DRuntimeTest.cpp
|--- openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DRuntimeTest.cpp	Tue Feb 01 19:38:05 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DRuntimeTest.cpp using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DRuntimeTest.h
|--- openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DRuntimeTest.h	Tue Feb 01 19:38:05 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DRuntimeTest.h using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DShaderGen.c
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DShaderGen.c	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DShaderGen.c...)
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DShaderGen.c using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DShaders.h
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DShaders.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DShaders.h...)
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DShaders.h using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DSurfaceData.cpp
|--- openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DSurfaceData.cpp	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DSurfaceData.cpp	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DSurfaceData.cpp using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 23.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DSurfaceData.h
|--- openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DSurfaceData.h	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DSurfaceData.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DSurfaceData.h using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 23.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DTestRaster.h
|--- openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DTestRaster.h	Tue Feb 01 19:38:05 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DTestRaster.h using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DTextRenderer.cpp
|--- openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DTextRenderer.cpp	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DTextRenderer.cpp	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DTextRenderer.cpp using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 24.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DTextRenderer.h
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DTextRenderer.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DTextRenderer.h...)
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DTextRenderer.h using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DTextRenderer_md.cpp
|--- openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DTextRenderer_md.cpp	Tue Feb 01 19:38:05 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DTextRenderer_md.cpp using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DUtils.cpp
|--- openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DUtils.cpp	Tue Feb 01 19:38:05 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DUtils.cpp using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DUtils.h
|--- openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DUtils.h	Tue Feb 01 19:38:05 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DUtils.h using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DVertexCacher.cpp
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DVertexCacher.cpp	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DVertexCacher.cpp...)
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DVertexCacher.cpp using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/d3d/D3DVertexCacher.h
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DVertexCacher.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DVertexCacher.h...)
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DVertexCacher.h using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/opengl/WGLGraphicsConfig.c
|--- openjdk/jdk/src/windows/native/sun/java2d/opengl/WGLGraphicsConfig.c	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/opengl/WGLGraphicsConfig.c	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/opengl/WGLGraphicsConfig.c using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 501.
Hunk #3 succeeded at 626.
Hunk #4 succeeded at 712.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/opengl/WGLSurfaceData.c
|--- openjdk/jdk/src/windows/native/sun/java2d/opengl/WGLSurfaceData.c	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/opengl/WGLSurfaceData.c	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/opengl/WGLSurfaceData.c using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 44.
Hunk #3 succeeded at 81.
Hunk #4 succeeded at 113.
Hunk #5 succeeded at 273.
Hunk #6 succeeded at 301.
Hunk #7 succeeded at 314.
Hunk #8 succeeded at 357.
Hunk #9 succeeded at 386.
Hunk #10 succeeded at 521.
Hunk #11 succeeded at 561.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/opengl/WGLSurfaceData.h
|--- openjdk/jdk/src/windows/native/sun/java2d/opengl/WGLSurfaceData.h	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/opengl/WGLSurfaceData.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/opengl/WGLSurfaceData.h using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 35.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/windows/DDBlitLoops.cpp
|--- openjdk/jdk/src/windows/native/sun/java2d/windows/DDBlitLoops.cpp	Tue Feb 01 19:38:05 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/windows/DDBlitLoops.cpp using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/windows/DDRenderer.cpp
|--- openjdk/jdk/src/windows/native/sun/java2d/windows/DDRenderer.cpp	Tue Feb 01 19:38:05 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/windows/DDRenderer.cpp using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/windows/GDIBlitLoops.cpp
|--- openjdk/jdk/src/windows/native/sun/java2d/windows/GDIBlitLoops.cpp	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/windows/GDIBlitLoops.cpp	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/windows/GDIBlitLoops.cpp using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 25.
Hunk #3 succeeded at 60.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/windows/GDIRenderer.cpp
|--- openjdk/jdk/src/windows/native/sun/java2d/windows/GDIRenderer.cpp	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/windows/GDIRenderer.cpp	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/windows/GDIRenderer.cpp using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 26.
Hunk #3 succeeded at 132.
Hunk #4 succeeded at 183.
Hunk #5 succeeded at 240.
Hunk #6 succeeded at 278.
Hunk #7 succeeded at 314.
Hunk #8 succeeded at 384.
Hunk #9 succeeded at 431.
Hunk #10 succeeded at 475.
Hunk #11 succeeded at 542.
Hunk #12 succeeded at 588.
Hunk #13 succeeded at 651.
Hunk #14 succeeded at 697.
Hunk #15 succeeded at 848.
Hunk #16 succeeded at 875.
Hunk #17 succeeded at 889.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.cpp
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.cpp	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.cpp...)
Patching file openjdk/jdk/src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.cpp using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.h
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.h...)
Patching file openjdk/jdk/src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.h using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/windows/RegistryKey.cpp
|--- openjdk/jdk/src/windows/native/sun/java2d/windows/RegistryKey.cpp	Tue Feb 01 19:38:05 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/windows/RegistryKey.cpp using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/windows/RegistryKey.h
|--- openjdk/jdk/src/windows/native/sun/java2d/windows/RegistryKey.h	Tue Feb 01 19:38:05 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/windows/RegistryKey.h using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/windows/Win32OffScreenSurfaceData.cpp
|--- openjdk/jdk/src/windows/native/sun/java2d/windows/Win32OffScreenSurfaceData.cpp	Tue Feb 01 19:38:05 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/windows/Win32OffScreenSurfaceData.cpp using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/windows/Win32SurfaceData.cpp
|--- openjdk/jdk/src/windows/native/sun/java2d/windows/Win32SurfaceData.cpp	Tue Feb 01 19:38:05 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/windows/Win32SurfaceData.cpp using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/windows/Win32SurfaceData.h
|--- openjdk/jdk/src/windows/native/sun/java2d/windows/Win32SurfaceData.h	Tue Feb 01 19:38:05 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/windows/Win32SurfaceData.h using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/windows/WinBackBufferSurfaceData.cpp
|--- openjdk/jdk/src/windows/native/sun/java2d/windows/WinBackBufferSurfaceData.cpp	Tue Feb 01 19:38:05 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/windows/WinBackBufferSurfaceData.cpp using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/windows/WindowsFlags.cpp
|--- openjdk/jdk/src/windows/native/sun/java2d/windows/WindowsFlags.cpp	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/windows/WindowsFlags.cpp	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/windows/WindowsFlags.cpp using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 28.
Hunk #3 succeeded at 40.
Hunk #4 succeeded at 66.
Hunk #5 succeeded at 89.
Hunk #6 succeeded at 131.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/windows/WindowsFlags.h
|--- openjdk/jdk/src/windows/native/sun/java2d/windows/WindowsFlags.h	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/native/sun/java2d/windows/WindowsFlags.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/windows/WindowsFlags.h using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 27.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/windows/ddrawObject.cpp
|--- openjdk/jdk/src/windows/native/sun/java2d/windows/ddrawObject.cpp	Tue Feb 01 19:38:05 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/windows/ddrawObject.cpp using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/windows/ddrawObject.h
|--- openjdk/jdk/src/windows/native/sun/java2d/windows/ddrawObject.h	Tue Feb 01 19:38:05 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/windows/ddrawObject.h using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/windows/ddrawUtils.cpp
|--- openjdk/jdk/src/windows/native/sun/java2d/windows/ddrawUtils.cpp	Tue Feb 01 19:38:05 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/windows/ddrawUtils.cpp using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/windows/ddrawUtils.h
|--- openjdk/jdk/src/windows/native/sun/java2d/windows/ddrawUtils.h	Tue Feb 01 19:38:05 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/windows/ddrawUtils.h using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/windows/dxCapabilities.cpp
|--- openjdk/jdk/src/windows/native/sun/java2d/windows/dxCapabilities.cpp	Tue Feb 01 19:38:05 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/windows/dxCapabilities.cpp using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/windows/dxCapabilities.h
|--- openjdk/jdk/src/windows/native/sun/java2d/windows/dxCapabilities.h	Tue Feb 01 19:38:05 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/windows/dxCapabilities.h using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/windows/dxInit.cpp
|--- openjdk/jdk/src/windows/native/sun/java2d/windows/dxInit.cpp	Tue Feb 01 19:38:05 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/windows/dxInit.cpp using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/java2d/windows/dxInit.h
|--- openjdk/jdk/src/windows/native/sun/java2d/windows/dxInit.h	Tue Feb 01 19:38:05 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/windows/dxInit.h using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/windows/Devices.cpp
|--- openjdk/jdk/src/windows/native/sun/windows/Devices.cpp	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/native/sun/windows/Devices.cpp	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/Devices.cpp using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 84.
Hunk #3 succeeded at 134.
Hunk #4 succeeded at 161.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/windows/awt.h
|--- openjdk/jdk/src/windows/native/sun/windows/awt.h	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/native/sun/windows/awt.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt.h using Plan A...
Hunk #1 succeeded at 144.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/windows/awt_Component.cpp
|--- openjdk/jdk/src/windows/native/sun/windows/awt_Component.cpp	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_Component.cpp	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_Component.cpp using Plan A...
Hunk #1 succeeded at 45.
Hunk #2 succeeded at 164.
Hunk #3 succeeded at 416.
Hunk #4 succeeded at 1941.
Hunk #5 succeeded at 2203.
Hunk #6 succeeded at 4757.
Hunk #7 succeeded at 5301.
Hunk #8 succeeded at 5820 (offset 6 lines).
Hunk #9 succeeded at 6368 (offset 6 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/windows/awt_Component.h
|--- openjdk/jdk/src/windows/native/sun/windows/awt_Component.h	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_Component.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_Component.h using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 32.
Hunk #3 succeeded at 62.
Hunk #4 succeeded at 201.
Hunk #5 succeeded at 599.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/windows/awt_DrawingSurface.cpp
|--- openjdk/jdk/src/windows/native/sun/windows/awt_DrawingSurface.cpp	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_DrawingSurface.cpp	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_DrawingSurface.cpp using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 25.
Hunk #3 succeeded at 80.
Hunk #4 succeeded at 222.
Hunk #5 succeeded at 241.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/windows/awt_DrawingSurface.h
|--- openjdk/jdk/src/windows/native/sun/windows/awt_DrawingSurface.h	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_DrawingSurface.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_DrawingSurface.h using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 30.
Hunk #3 succeeded at 84.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/windows/awt_Toolkit.cpp
|--- openjdk/jdk/src/windows/native/sun/windows/awt_Toolkit.cpp	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_Toolkit.cpp	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_Toolkit.cpp using Plan A...
Hunk #1 succeeded at 52.
Hunk #2 succeeded at 79.
Hunk #3 succeeded at 270.
Hunk #4 succeeded at 452.
Hunk #5 succeeded at 689.
Hunk #6 succeeded at 723.
Hunk #7 succeeded at 882.
Hunk #8 succeeded at 1542.
Hunk #9 succeeded at 1554.
Hunk #10 succeeded at 1860.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/windows/awt_Win32GraphicsDevice.cpp
|--- openjdk/jdk/src/windows/native/sun/windows/awt_Win32GraphicsDevice.cpp	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_Win32GraphicsDevice.cpp	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_Win32GraphicsDevice.cpp using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 43.
Hunk #3 succeeded at 59.
Hunk #4 succeeded at 453.
Hunk #5 succeeded at 600.
Hunk #6 succeeded at 609.
Hunk #7 succeeded at 682.
Hunk #8 succeeded at 830.
Hunk #9 succeeded at 839.
Hunk #10 succeeded at 979.
Hunk #11 succeeded at 990.
Hunk #12 succeeded at 1010.
Hunk #13 succeeded at 1021.
Hunk #14 succeeded at 1059.
Hunk #15 succeeded at 1101.
Hunk #16 succeeded at 1134.
Hunk #17 succeeded at 1183.
Hunk #18 succeeded at 1211.
Hunk #19 succeeded at 1222.
Hunk #20 succeeded at 1272.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/windows/awt_Win32GraphicsDevice.h
|--- openjdk/jdk/src/windows/native/sun/windows/awt_Win32GraphicsDevice.h	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_Win32GraphicsDevice.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_Win32GraphicsDevice.h using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 34.
Hunk #3 succeeded at 62.
Hunk #4 succeeded at 84.
Hunk #5 succeeded at 94.
Hunk #6 succeeded at 108.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp
|--- openjdk/jdk/src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 31.
Hunk #3 succeeded at 40.
Hunk #4 succeeded at 53.
Hunk #5 succeeded at 63.
Hunk #6 succeeded at 76.
Hunk #7 succeeded at 158.
Hunk #8 succeeded at 377.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/windows/awt_Window.cpp
|--- openjdk/jdk/src/windows/native/sun/windows/awt_Window.cpp	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_Window.cpp	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_Window.cpp using Plan A...
Hunk #1 succeeded at 33.
Hunk #2 succeeded at 738 (offset -4 lines).
Hunk #3 succeeded at 927 (offset -4 lines).
Hunk #4 succeeded at 1285 (offset -4 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/windows/awt_Window.h
|--- openjdk/jdk/src/windows/native/sun/windows/awt_Window.h	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_Window.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_Window.h using Plan A...
Hunk #1 succeeded at 161 (offset -6 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d src/windows/native/sun/windows/awtmsg.h
|--- openjdk/jdk/src/windows/native/sun/windows/awtmsg.h	Tue Feb 01 19:38:05 2011 +0000
|+++ openjdk/jdk/src/windows/native/sun/windows/awtmsg.h	Fri Feb 04 16:32:49 2011 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awtmsg.h using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 252.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d test/java/awt/FullScreen/BufferStrategyExceptionTest/BufferStrategyExceptionTest.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/java/awt/FullScreen/BufferStrategyExceptionTest/BufferStrategyExceptionTest.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/test/java/awt/FullScreen/BufferStrategyExceptionTest/BufferStrategyExceptionTest.java...)
Patching file openjdk/jdk/test/java/awt/FullScreen/BufferStrategyExceptionTest/BufferStrategyExceptionTest.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d test/java/awt/FullScreen/MultimonFullscreenTest/MultimonFullscreenTest.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/java/awt/FullScreen/MultimonFullscreenTest/MultimonFullscreenTest.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/test/java/awt/FullScreen/MultimonFullscreenTest/MultimonFullscreenTest.java...)
Patching file openjdk/jdk/test/java/awt/FullScreen/MultimonFullscreenTest/MultimonFullscreenTest.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d test/java/awt/FullScreen/NoResizeEventOnDMChangeTest/NoResizeEventOnDMChangeTest.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/java/awt/FullScreen/NoResizeEventOnDMChangeTest/NoResizeEventOnDMChangeTest.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/test/java/awt/FullScreen/NoResizeEventOnDMChangeTest/NoResizeEventOnDMChangeTest.java...)
Patching file openjdk/jdk/test/java/awt/FullScreen/NoResizeEventOnDMChangeTest/NoResizeEventOnDMChangeTest.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d test/java/awt/FullScreen/SetFSWindow/FSFrame.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/java/awt/FullScreen/SetFSWindow/FSFrame.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/test/java/awt/FullScreen/SetFSWindow/FSFrame.java...)
Patching file openjdk/jdk/test/java/awt/FullScreen/SetFSWindow/FSFrame.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d test/java/awt/Multiscreen/DeviceIdentificationTest/DeviceIdentificationTest.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/java/awt/Multiscreen/DeviceIdentificationTest/DeviceIdentificationTest.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/test/java/awt/Multiscreen/DeviceIdentificationTest/DeviceIdentificationTest.java...)
Patching file openjdk/jdk/test/java/awt/Multiscreen/DeviceIdentificationTest/DeviceIdentificationTest.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d test/java/awt/image/MemoryLeakTest/MemoryLeakTest.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/java/awt/image/MemoryLeakTest/MemoryLeakTest.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/test/java/awt/image/MemoryLeakTest/MemoryLeakTest.java...)
Patching file openjdk/jdk/test/java/awt/image/MemoryLeakTest/MemoryLeakTest.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d test/sun/java2d/DirectX/AccelPaintsTest/AccelPaintsTest.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/sun/java2d/DirectX/AccelPaintsTest/AccelPaintsTest.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/test/sun/java2d/DirectX/AccelPaintsTest/AccelPaintsTest.java...)
Patching file openjdk/jdk/test/sun/java2d/DirectX/AccelPaintsTest/AccelPaintsTest.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d test/sun/java2d/DirectX/AcceleratedScaleTest/AcceleratedScaleTest.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/sun/java2d/DirectX/AcceleratedScaleTest/AcceleratedScaleTest.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/test/sun/java2d/DirectX/AcceleratedScaleTest/AcceleratedScaleTest.java...)
Patching file openjdk/jdk/test/sun/java2d/DirectX/AcceleratedScaleTest/AcceleratedScaleTest.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d test/sun/java2d/DirectX/IAEforEmptyFrameTest/IAEforEmptyFrameTest.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/sun/java2d/DirectX/IAEforEmptyFrameTest/IAEforEmptyFrameTest.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/test/sun/java2d/DirectX/IAEforEmptyFrameTest/IAEforEmptyFrameTest.java...)
Patching file openjdk/jdk/test/sun/java2d/DirectX/IAEforEmptyFrameTest/IAEforEmptyFrameTest.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d test/sun/java2d/DirectX/InfiniteValidationLoopTest/InfiniteValidationLoopTest.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/sun/java2d/DirectX/InfiniteValidationLoopTest/InfiniteValidationLoopTest.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/test/sun/java2d/DirectX/InfiniteValidationLoopTest/InfiniteValidationLoopTest.java...)
Patching file openjdk/jdk/test/sun/java2d/DirectX/InfiniteValidationLoopTest/InfiniteValidationLoopTest.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d test/sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/test/sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java...)
Patching file openjdk/jdk/test/sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d test/sun/java2d/DirectX/OverriddenInsetsTest/OverriddenInsetsTest.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/sun/java2d/DirectX/OverriddenInsetsTest/OverriddenInsetsTest.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/test/sun/java2d/DirectX/OverriddenInsetsTest/OverriddenInsetsTest.java...)
Patching file openjdk/jdk/test/sun/java2d/DirectX/OverriddenInsetsTest/OverriddenInsetsTest.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d test/sun/java2d/DirectX/RenderingToCachedGraphicsTest/RenderingToCachedGraphicsTest.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/sun/java2d/DirectX/RenderingToCachedGraphicsTest/RenderingToCachedGraphicsTest.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/test/sun/java2d/DirectX/RenderingToCachedGraphicsTest/RenderingToCachedGraphicsTest.java...)
Patching file openjdk/jdk/test/sun/java2d/DirectX/RenderingToCachedGraphicsTest/RenderingToCachedGraphicsTest.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d test/sun/java2d/DirectX/StrikeDisposalCrashTest/StrikeDisposalCrashTest.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/sun/java2d/DirectX/StrikeDisposalCrashTest/StrikeDisposalCrashTest.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/test/sun/java2d/DirectX/StrikeDisposalCrashTest/StrikeDisposalCrashTest.java...)
Patching file openjdk/jdk/test/sun/java2d/DirectX/StrikeDisposalCrashTest/StrikeDisposalCrashTest.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d test/sun/java2d/DirectX/SwingOnScreenScrollingTest/SwingOnScreenScrollingTest.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/sun/java2d/DirectX/SwingOnScreenScrollingTest/SwingOnScreenScrollingTest.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/test/sun/java2d/DirectX/SwingOnScreenScrollingTest/SwingOnScreenScrollingTest.java...)
Patching file openjdk/jdk/test/sun/java2d/DirectX/SwingOnScreenScrollingTest/SwingOnScreenScrollingTest.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d test/sun/java2d/DirectX/TransformedPaintTest/TransformedPaintTest.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/sun/java2d/DirectX/TransformedPaintTest/TransformedPaintTest.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/test/sun/java2d/DirectX/TransformedPaintTest/TransformedPaintTest.java...)
Patching file openjdk/jdk/test/sun/java2d/DirectX/TransformedPaintTest/TransformedPaintTest.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d test/sun/java2d/GdiRendering/InsetClipping.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/sun/java2d/GdiRendering/InsetClipping.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/test/sun/java2d/GdiRendering/InsetClipping.java...)
Patching file openjdk/jdk/test/sun/java2d/GdiRendering/InsetClipping.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d test/sun/java2d/OpenGL/DrawBufImgOp.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/sun/java2d/OpenGL/DrawBufImgOp.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/test/sun/java2d/OpenGL/DrawBufImgOp.java...)
Patching file openjdk/jdk/test/sun/java2d/OpenGL/DrawBufImgOp.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d test/sun/java2d/SunGraphics2D/DrawImageBilinear.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/sun/java2d/SunGraphics2D/DrawImageBilinear.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/test/sun/java2d/SunGraphics2D/DrawImageBilinear.java...)
Patching file openjdk/jdk/test/sun/java2d/SunGraphics2D/DrawImageBilinear.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d test/sun/java2d/SunGraphics2D/PolyVertTest.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/sun/java2d/SunGraphics2D/PolyVertTest.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/test/sun/java2d/SunGraphics2D/PolyVertTest.java...)
Patching file openjdk/jdk/test/sun/java2d/SunGraphics2D/PolyVertTest.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d test/sun/java2d/SunGraphics2D/SimplePrimQuality.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/sun/java2d/SunGraphics2D/SimplePrimQuality.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/test/sun/java2d/SunGraphics2D/SimplePrimQuality.java...)
Patching file openjdk/jdk/test/sun/java2d/SunGraphics2D/SimplePrimQuality.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d test/sun/java2d/SunGraphics2D/SourceClippingBlitTest/SourceClippingBlitTest.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/sun/java2d/SunGraphics2D/SourceClippingBlitTest/SourceClippingBlitTest.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/test/sun/java2d/SunGraphics2D/SourceClippingBlitTest/SourceClippingBlitTest.java...)
Patching file openjdk/jdk/test/sun/java2d/SunGraphics2D/SourceClippingBlitTest/SourceClippingBlitTest.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d test/sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/test/sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.java...)
Patching file openjdk/jdk/test/sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d test/sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.sh
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.sh	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/test/sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.sh...)
Patching file openjdk/jdk/test/sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.sh using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d test/sun/java2d/pipe/MutableColorTest/MutableColorTest.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/sun/java2d/pipe/MutableColorTest/MutableColorTest.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/test/sun/java2d/pipe/MutableColorTest/MutableColorTest.java...)
Patching file openjdk/jdk/test/sun/java2d/pipe/MutableColorTest/MutableColorTest.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d test/sun/java2d/pipe/hw/RSLAPITest/RSLAPITest.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/sun/java2d/pipe/hw/RSLAPITest/RSLAPITest.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/test/sun/java2d/pipe/hw/RSLAPITest/RSLAPITest.java...)
Patching file openjdk/jdk/test/sun/java2d/pipe/hw/RSLAPITest/RSLAPITest.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f683aef58585 -r 6cf33f955d7d test/sun/java2d/pipe/hw/VSyncedBufferStrategyTest/VSyncedBufferStrategyTest.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/sun/java2d/pipe/hw/VSyncedBufferStrategyTest/VSyncedBufferStrategyTest.java	Fri Feb 04 16:32:49 2011 +0000
--------------------------
(Creating file openjdk/jdk/test/sun/java2d/pipe/hw/VSyncedBufferStrategyTest/VSyncedBufferStrategyTest.java...)
Patching file openjdk/jdk/test/sun/java2d/pipe/hw/VSyncedBufferStrategyTest/VSyncedBufferStrategyTest.java using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/openjdk/6748082-isDisplayLocal.patch
Applying patches/openjdk/6748082-isDisplayLocal.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User tdv
|# Date 1221256905 25200
|# Node ID b8f91ea2fb33cdbbc177ab1f68170ce7966b5d7b
|# Parent  cd88b4ad7f258f023f12ebcc3b5a01a826e9392d
|6748082: remove platform-specific code from SwingUtilities2.isDisplayLocal
|Reviewed-by: prr, tdv
|Contributed-by: rkennke at kennke.org
|
|diff -r cd88b4ad7f25 -r b8f91ea2fb33 src/share/classes/sun/java2d/SunGraphicsEnvironment.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/SunGraphicsEnvironment.java	Thu Aug 28 11:27:14 2008 -0700
|+++ openjdk/jdk/src/share/classes/sun/java2d/SunGraphicsEnvironment.java	Fri Sep 12 15:01:45 2008 -0700
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/SunGraphicsEnvironment.java using Plan A...
Hunk #1 succeeded at 1253 (offset -19 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r cd88b4ad7f25 -r b8f91ea2fb33 src/share/classes/sun/swing/SwingUtilities2.java
|--- openjdk.orig/jdk/src/share/classes/sun/swing/SwingUtilities2.java	Thu Aug 28 11:27:14 2008 -0700
|+++ openjdk/jdk/src/share/classes/sun/swing/SwingUtilities2.java	Fri Sep 12 15:01:45 2008 -0700
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/swing/SwingUtilities2.java using Plan A...
Hunk #1 succeeded at 48 (offset -7 lines).
Hunk #2 succeeded at 1479 (offset -4 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r cd88b4ad7f25 -r b8f91ea2fb33 src/solaris/classes/sun/awt/X11GraphicsEnvironment.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/X11GraphicsEnvironment.java	Thu Aug 28 11:27:14 2008 -0700
|+++ openjdk/jdk/src/solaris/classes/sun/awt/X11GraphicsEnvironment.java	Fri Sep 12 15:01:45 2008 -0700
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/X11GraphicsEnvironment.java using Plan A...
Hunk #1 succeeded at 202 (offset -7 lines).
Hunk #2 succeeded at 227 (offset -7 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r cd88b4ad7f25 -r b8f91ea2fb33 src/solaris/native/sun/awt/fontpath.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/fontpath.c	Thu Aug 28 11:27:14 2008 -0700
|+++ openjdk/jdk/src/solaris/native/sun/awt/fontpath.c	Fri Sep 12 15:01:45 2008 -0700
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/fontpath.c using Plan A...
Hunk #1 succeeded at 156.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r cd88b4ad7f25 -r b8f91ea2fb33 src/windows/classes/sun/awt/Win32GraphicsEnvironment.java
|--- openjdk.orig/jdk/src/windows/classes/sun/awt/Win32GraphicsEnvironment.java	Thu Aug 28 11:27:14 2008 -0700
|+++ openjdk/jdk/src/windows/classes/sun/awt/Win32GraphicsEnvironment.java	Fri Sep 12 15:01:45 2008 -0700
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/awt/Win32GraphicsEnvironment.java using Plan A...
Hunk #1 succeeded at 379 (offset -14 lines).
Hmm...  Ignoring the trailing garbage.
done
Checking patches/openjdk/6633275-shaped_translucent_windows.patch
Applying patches/openjdk/6633275-shaped_translucent_windows.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/sun/awt/FILES_c_windows.gmk openjdk/jdk/make/sun/awt/FILES_c_windows.gmk
|--- openjdk.orig/jdk/make/sun/awt/FILES_c_windows.gmk	2011-05-18 15:58:49.000000000 +0100
|+++ openjdk/jdk/make/sun/awt/FILES_c_windows.gmk	2011-05-18 16:12:18.052791528 +0100
--------------------------
Patching file openjdk/jdk/make/sun/awt/FILES_c_windows.gmk using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 104.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/sun/awt/make.depend openjdk/jdk/make/sun/awt/make.depend
|--- openjdk.orig/jdk/make/sun/awt/make.depend	2011-05-18 15:58:49.000000000 +0100
|+++ openjdk/jdk/make/sun/awt/make.depend	2011-05-18 16:12:18.068791794 +0100
--------------------------
Patching file openjdk/jdk/make/sun/awt/make.depend using Plan A...
Hunk #1 succeeded at 16.
Hunk #2 succeeded at 32.
Hunk #3 succeeded at 150.
Hunk #4 succeeded at 246.
Hunk #5 succeeded at 278.
Hunk #6 succeeded at 290.
Hunk #7 succeeded at 312.
Hunk #8 succeeded at 332.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/sun/awt/Makefile openjdk/jdk/make/sun/awt/Makefile
|--- openjdk.orig/jdk/make/sun/awt/Makefile	2011-05-18 15:58:49.000000000 +0100
|+++ openjdk/jdk/make/sun/awt/Makefile	2011-05-18 16:12:18.076791927 +0100
--------------------------
Patching file openjdk/jdk/make/sun/awt/Makefile using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 224.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/sun/awt/mapfile-mawt-vers openjdk/jdk/make/sun/awt/mapfile-mawt-vers
|--- openjdk.orig/jdk/make/sun/awt/mapfile-mawt-vers	2011-05-18 15:58:49.000000000 +0100
|+++ openjdk/jdk/make/sun/awt/mapfile-mawt-vers	2011-05-18 16:12:18.088792126 +0100
--------------------------
Patching file openjdk/jdk/make/sun/awt/mapfile-mawt-vers using Plan A...
Hunk #1 succeeded at 291.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/sun/awt/mapfile-vers-linux openjdk/jdk/make/sun/awt/mapfile-vers-linux
|--- openjdk.orig/jdk/make/sun/awt/mapfile-vers-linux	2011-05-18 15:58:49.000000000 +0100
|+++ openjdk/jdk/make/sun/awt/mapfile-vers-linux	2011-05-18 16:12:18.088792126 +0100
--------------------------
Patching file openjdk/jdk/make/sun/awt/mapfile-vers-linux using Plan A...
Hunk #1 succeeded at 406.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/sun/xawt/mapfile-vers openjdk/jdk/make/sun/xawt/mapfile-vers
|--- openjdk.orig/jdk/make/sun/xawt/mapfile-vers	2011-05-18 15:58:49.000000000 +0100
|+++ openjdk/jdk/make/sun/xawt/mapfile-vers	2011-05-18 16:12:18.088792126 +0100
--------------------------
Patching file openjdk/jdk/make/sun/xawt/mapfile-vers using Plan A...
Hunk #1 succeeded at 216.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/classes/com/sun/awt/AWTUtilities.java openjdk/jdk/src/share/classes/com/sun/awt/AWTUtilities.java
|--- openjdk.orig/jdk/src/share/classes/com/sun/awt/AWTUtilities.java	2011-05-18 15:58:48.000000000 +0100
|+++ openjdk/jdk/src/share/classes/com/sun/awt/AWTUtilities.java	2011-05-18 16:12:18.088792126 +0100
--------------------------
Patching file openjdk/jdk/src/share/classes/com/sun/awt/AWTUtilities.java using Plan A...
Hunk #1 succeeded at 26.
Hunk #2 succeeded at 70.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/classes/java/awt/Component.java openjdk/jdk/src/share/classes/java/awt/Component.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/Component.java	2011-05-18 15:58:49.000000000 +0100
|+++ openjdk/jdk/src/share/classes/java/awt/Component.java	2011-05-18 16:12:18.088792126 +0100
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/Component.java using Plan A...
Hunk #1 succeeded at 806.
Hunk #2 succeeded at 7463.
Hunk #3 succeeded at 8698 (offset 4 lines).
Hunk #4 succeeded at 9814 (offset 4 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/classes/java/awt/Container.java openjdk/jdk/src/share/classes/java/awt/Container.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/Container.java	2011-05-18 15:58:48.000000000 +0100
|+++ openjdk/jdk/src/share/classes/java/awt/Container.java	2011-05-18 16:12:18.092792193 +0100
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/Container.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 167.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/classes/java/awt/DefaultKeyboardFocusManager.java openjdk/jdk/src/share/classes/java/awt/DefaultKeyboardFocusManager.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/DefaultKeyboardFocusManager.java	2011-05-18 15:58:48.000000000 +0100
|+++ openjdk/jdk/src/share/classes/java/awt/DefaultKeyboardFocusManager.java	2011-05-18 16:12:18.092792193 +0100
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/DefaultKeyboardFocusManager.java using Plan A...
Hunk #1 succeeded at 480.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/classes/java/awt/GraphicsConfiguration.java openjdk/jdk/src/share/classes/java/awt/GraphicsConfiguration.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/GraphicsConfiguration.java	2011-01-07 21:32:53.000000000 +0000
|+++ openjdk/jdk/src/share/classes/java/awt/GraphicsConfiguration.java	2011-05-18 16:12:18.092792193 +0100
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/GraphicsConfiguration.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 428.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/classes/java/awt/GraphicsDevice.java openjdk/jdk/src/share/classes/java/awt/GraphicsDevice.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/GraphicsDevice.java	2011-05-18 15:58:49.000000000 +0100
|+++ openjdk/jdk/src/share/classes/java/awt/GraphicsDevice.java	2011-05-18 16:12:18.092792193 +0100
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/GraphicsDevice.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 27.
Hunk #3 succeeded at 112.
Hunk #4 succeeded at 263.
Hunk #5 succeeded at 467.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/classes/java/awt/KeyboardFocusManager.java openjdk/jdk/src/share/classes/java/awt/KeyboardFocusManager.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/KeyboardFocusManager.java	2011-05-18 15:58:48.000000000 +0100
|+++ openjdk/jdk/src/share/classes/java/awt/KeyboardFocusManager.java	2011-05-18 16:12:18.092792193 +0100
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/KeyboardFocusManager.java using Plan A...
Hunk #1 succeeded at 2189 (offset -21 lines).
Hunk #2 succeeded at 2523 (offset -21 lines).
Hunk #3 succeeded at 2994 (offset -21 lines).
Hunk #4 succeeded at 3009 (offset -21 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/classes/java/awt/peer/WindowPeer.java openjdk/jdk/src/share/classes/java/awt/peer/WindowPeer.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/peer/WindowPeer.java	2011-01-07 21:32:53.000000000 +0000
|+++ openjdk/jdk/src/share/classes/java/awt/peer/WindowPeer.java	2011-05-18 16:12:18.096792260 +0100
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/peer/WindowPeer.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 27.
Hunk #3 succeeded at 45.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/classes/java/awt/Window.java openjdk/jdk/src/share/classes/java/awt/Window.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/Window.java	2011-01-07 21:32:53.000000000 +0000
|+++ openjdk/jdk/src/share/classes/java/awt/Window.java	2011-05-18 16:12:18.096792260 +0100
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/Window.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 28.
Hunk #3 succeeded at 51.
Hunk #4 succeeded at 293.
Hunk #5 succeeded at 682.
Hunk #6 succeeded at 2786.
Hunk #7 succeeded at 3205 (offset -2 lines).
Hunk #8 succeeded at 3461 (offset -2 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/classes/javax/swing/RepaintManager.java openjdk/jdk/src/share/classes/javax/swing/RepaintManager.java
|--- openjdk.orig/jdk/src/share/classes/javax/swing/RepaintManager.java	2011-01-07 21:32:57.000000000 +0000
|+++ openjdk/jdk/src/share/classes/javax/swing/RepaintManager.java	2011-05-18 16:12:18.096792260 +0100
--------------------------
Patching file openjdk/jdk/src/share/classes/javax/swing/RepaintManager.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 34.
Hunk #3 succeeded at 682.
Hunk #4 succeeded at 753.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/classes/sun/awt/AWTAccessor.java openjdk/jdk/src/share/classes/sun/awt/AWTAccessor.java
|--- openjdk.orig/jdk/src/share/classes/sun/awt/AWTAccessor.java	2011-05-18 15:58:48.000000000 +0100
|+++ openjdk/jdk/src/share/classes/sun/awt/AWTAccessor.java	2011-05-18 16:12:18.096792260 +0100
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/awt/AWTAccessor.java using Plan A...
Hunk #1 succeeded at 59.
Hunk #2 succeeded at 91.
Hunk #3 succeeded at 155.
Hunk #4 succeeded at 199.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/classes/sun/awt/EmbeddedFrame.java openjdk/jdk/src/share/classes/sun/awt/EmbeddedFrame.java
|--- openjdk.orig/jdk/src/share/classes/sun/awt/EmbeddedFrame.java	2011-01-07 21:32:58.000000000 +0000
|+++ openjdk/jdk/src/share/classes/sun/awt/EmbeddedFrame.java	2011-05-18 16:12:18.096792260 +0100
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/awt/EmbeddedFrame.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 579.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/classes/sun/awt/SunToolkit.java openjdk/jdk/src/share/classes/sun/awt/SunToolkit.java
|--- openjdk.orig/jdk/src/share/classes/sun/awt/SunToolkit.java	2011-05-18 15:58:48.000000000 +0100
|+++ openjdk/jdk/src/share/classes/sun/awt/SunToolkit.java	2011-05-18 16:12:18.096792260 +0100
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/awt/SunToolkit.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 32.
Hunk #3 succeeded at 45.
Hunk #4 succeeded at 819.
Hunk #5 succeeded at 1982.
Hunk #6 succeeded at 2017.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/native/sun/awt/utility/rect.c openjdk/jdk/src/share/native/sun/awt/utility/rect.c
|--- openjdk.orig/jdk/src/share/native/sun/awt/utility/rect.c	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/src/share/native/sun/awt/utility/rect.c	2011-05-18 16:12:18.096792260 +0100
--------------------------
(Creating file openjdk/jdk/src/share/native/sun/awt/utility/rect.c...)
Patching file openjdk/jdk/src/share/native/sun/awt/utility/rect.c using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/generator/WrapperGenerator.java openjdk/jdk/src/solaris/classes/sun/awt/X11/generator/WrapperGenerator.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/generator/WrapperGenerator.java	2011-01-07 21:33:04.000000000 +0000
|+++ openjdk/jdk/src/solaris/classes/sun/awt/X11/generator/WrapperGenerator.java	2011-05-18 16:12:18.100792327 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/X11/generator/WrapperGenerator.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 859.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/generator/xlibtypes.txt openjdk/jdk/src/solaris/classes/sun/awt/X11/generator/xlibtypes.txt
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/generator/xlibtypes.txt	2011-01-07 21:33:04.000000000 +0000
|+++ openjdk/jdk/src/solaris/classes/sun/awt/X11/generator/xlibtypes.txt	2011-05-18 16:12:18.100792327 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/X11/generator/xlibtypes.txt using Plan A...
Hunk #1 succeeded at 750.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/XNETProtocol.java openjdk/jdk/src/solaris/classes/sun/awt/X11/XNETProtocol.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/XNETProtocol.java	2011-01-07 21:33:04.000000000 +0000
|+++ openjdk/jdk/src/solaris/classes/sun/awt/X11/XNETProtocol.java	2011-05-18 16:12:18.100792327 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/X11/XNETProtocol.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 268.
Hunk #3 succeeded at 306.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/XToolkit.java openjdk/jdk/src/solaris/classes/sun/awt/X11/XToolkit.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/XToolkit.java	2011-01-07 21:33:04.000000000 +0000
|+++ openjdk/jdk/src/solaris/classes/sun/awt/X11/XToolkit.java	2011-05-18 16:12:18.100792327 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/X11/XToolkit.java using Plan A...
Hunk #1 succeeded at 2181.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/XWindowPeer.java openjdk/jdk/src/solaris/classes/sun/awt/X11/XWindowPeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/XWindowPeer.java	2011-01-07 21:33:04.000000000 +0000
|+++ openjdk/jdk/src/solaris/classes/sun/awt/X11/XWindowPeer.java	2011-05-18 16:12:18.100792327 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/X11/XWindowPeer.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 30.
Hunk #3 succeeded at 44.
Hunk #4 succeeded at 52.
Hunk #5 succeeded at 274.
Hunk #6 succeeded at 435.
Hunk #7 succeeded at 2147.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/X11GraphicsConfig.java openjdk/jdk/src/solaris/classes/sun/awt/X11GraphicsConfig.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/X11GraphicsConfig.java	2011-05-18 15:58:49.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/X11GraphicsConfig.java	2011-05-18 16:12:18.100792327 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/X11GraphicsConfig.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 458.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_GraphicsEnv.c openjdk/jdk/src/solaris/native/sun/awt/awt_GraphicsEnv.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_GraphicsEnv.c	2011-01-07 21:33:07.000000000 +0000
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_GraphicsEnv.c	2011-05-18 16:12:18.100792327 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_GraphicsEnv.c using Plan A...
Hunk #1 succeeded at 323.
Hunk #2 succeeded at 378.
Hunk #3 succeeded at 463.
Hunk #4 succeeded at 496.
Hunk #5 succeeded at 1554.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_p.h openjdk/jdk/src/solaris/native/sun/awt/awt_p.h
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_p.h	2011-01-07 21:33:07.000000000 +0000
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_p.h	2011-05-18 16:12:18.100792327 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_p.h using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 135.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/classes/sun/awt/Win32GraphicsConfig.java openjdk/jdk/src/windows/classes/sun/awt/Win32GraphicsConfig.java
|--- openjdk.orig/jdk/src/windows/classes/sun/awt/Win32GraphicsConfig.java	2011-05-18 15:58:49.000000000 +0100
|+++ openjdk/jdk/src/windows/classes/sun/awt/Win32GraphicsConfig.java	2011-05-18 16:12:18.100792327 +0100
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/awt/Win32GraphicsConfig.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 339.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/classes/sun/awt/Win32GraphicsEnvironment.java openjdk/jdk/src/windows/classes/sun/awt/Win32GraphicsEnvironment.java
|--- openjdk.orig/jdk/src/windows/classes/sun/awt/Win32GraphicsEnvironment.java	2011-05-18 15:58:49.000000000 +0100
|+++ openjdk/jdk/src/windows/classes/sun/awt/Win32GraphicsEnvironment.java	2011-05-18 16:12:18.104792394 +0100
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/awt/Win32GraphicsEnvironment.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 384.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/classes/sun/awt/windows/TranslucentWindowPainter.java openjdk/jdk/src/windows/classes/sun/awt/windows/TranslucentWindowPainter.java
|--- openjdk.orig/jdk/src/windows/classes/sun/awt/windows/TranslucentWindowPainter.java	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/src/windows/classes/sun/awt/windows/TranslucentWindowPainter.java	2011-05-18 16:12:18.104792394 +0100
--------------------------
(Creating file openjdk/jdk/src/windows/classes/sun/awt/windows/TranslucentWindowPainter.java...)
Patching file openjdk/jdk/src/windows/classes/sun/awt/windows/TranslucentWindowPainter.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/classes/sun/awt/windows/WCanvasPeer.java openjdk/jdk/src/windows/classes/sun/awt/windows/WCanvasPeer.java
|--- openjdk.orig/jdk/src/windows/classes/sun/awt/windows/WCanvasPeer.java	2011-01-07 21:33:07.000000000 +0000
|+++ openjdk/jdk/src/windows/classes/sun/awt/windows/WCanvasPeer.java	2011-05-18 16:12:18.104792394 +0100
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/awt/windows/WCanvasPeer.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 28.
Hunk #3 succeeded at 111.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/classes/sun/awt/windows/WComponentPeer.java openjdk/jdk/src/windows/classes/sun/awt/windows/WComponentPeer.java
|--- openjdk.orig/jdk/src/windows/classes/sun/awt/windows/WComponentPeer.java	2011-05-18 15:58:49.000000000 +0100
|+++ openjdk/jdk/src/windows/classes/sun/awt/windows/WComponentPeer.java	2011-05-18 16:12:18.104792394 +0100
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/awt/windows/WComponentPeer.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 39.
Hunk #3 succeeded at 194.
Hunk #4 succeeded at 266.
Hunk #5 succeeded at 903.
Hunk #6 succeeded at 917.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/classes/sun/awt/windows/WFileDialogPeer.java openjdk/jdk/src/windows/classes/sun/awt/windows/WFileDialogPeer.java
|--- openjdk.orig/jdk/src/windows/classes/sun/awt/windows/WFileDialogPeer.java	2011-01-07 21:33:07.000000000 +0000
|+++ openjdk/jdk/src/windows/classes/sun/awt/windows/WFileDialogPeer.java	2011-05-18 16:12:18.104792394 +0100
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/awt/windows/WFileDialogPeer.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 244.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/classes/sun/awt/windows/WPrintDialogPeer.java openjdk/jdk/src/windows/classes/sun/awt/windows/WPrintDialogPeer.java
|--- openjdk.orig/jdk/src/windows/classes/sun/awt/windows/WPrintDialogPeer.java	2011-01-07 21:33:07.000000000 +0000
|+++ openjdk/jdk/src/windows/classes/sun/awt/windows/WPrintDialogPeer.java	2011-05-18 16:12:18.104792394 +0100
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/awt/windows/WPrintDialogPeer.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 156.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/classes/sun/awt/windows/WToolkit.java openjdk/jdk/src/windows/classes/sun/awt/windows/WToolkit.java
|--- openjdk.orig/jdk/src/windows/classes/sun/awt/windows/WToolkit.java	2011-05-18 15:58:49.000000000 +0100
|+++ openjdk/jdk/src/windows/classes/sun/awt/windows/WToolkit.java	2011-05-18 16:12:18.104792394 +0100
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/awt/windows/WToolkit.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 966.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/classes/sun/awt/windows/WWindowPeer.java openjdk/jdk/src/windows/classes/sun/awt/windows/WWindowPeer.java
|--- openjdk.orig/jdk/src/windows/classes/sun/awt/windows/WWindowPeer.java	2011-01-07 21:33:07.000000000 +0000
|+++ openjdk/jdk/src/windows/classes/sun/awt/windows/WWindowPeer.java	2011-05-18 16:12:18.104792394 +0100
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/awt/windows/WWindowPeer.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 31.
Hunk #3 succeeded at 50.
Hunk #4 succeeded at 92.
Hunk #5 succeeded at 175.
Hunk #6 succeeded at 212.
Hunk #7 succeeded at 296.
Hunk #8 succeeded at 573.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/classes/sun/java2d/opengl/WGLSurfaceData.java openjdk/jdk/src/windows/classes/sun/java2d/opengl/WGLSurfaceData.java
|--- openjdk.orig/jdk/src/windows/classes/sun/java2d/opengl/WGLSurfaceData.java	2011-05-18 15:58:49.000000000 +0100
|+++ openjdk/jdk/src/windows/classes/sun/java2d/opengl/WGLSurfaceData.java	2011-05-18 16:12:18.112792526 +0100
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/java2d/opengl/WGLSurfaceData.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 72.
Hunk #3 succeeded at 92.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/native/sun/awt/utility/rect.h openjdk/jdk/src/windows/native/sun/awt/utility/rect.h
|--- openjdk.orig/jdk/src/windows/native/sun/awt/utility/rect.h	2011-01-07 21:33:08.000000000 +0000
|+++ openjdk/jdk/src/windows/native/sun/awt/utility/rect.h	2011-05-18 16:12:18.112792526 +0100
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/awt/utility/rect.h using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 43.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/native/sun/java2d/d3d/D3DSurfaceData.cpp openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DSurfaceData.cpp
|--- openjdk.orig/jdk/src/windows/native/sun/java2d/d3d/D3DSurfaceData.cpp	2011-05-18 15:58:49.000000000 +0100
|+++ openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DSurfaceData.cpp	2011-05-18 16:12:18.112792526 +0100
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/d3d/D3DSurfaceData.cpp using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 614.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/native/sun/java2d/opengl/WGLSurfaceData.c openjdk/jdk/src/windows/native/sun/java2d/opengl/WGLSurfaceData.c
|--- openjdk.orig/jdk/src/windows/native/sun/java2d/opengl/WGLSurfaceData.c	2011-05-18 15:58:49.000000000 +0100
|+++ openjdk/jdk/src/windows/native/sun/java2d/opengl/WGLSurfaceData.c	2011-05-18 16:12:18.112792526 +0100
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/opengl/WGLSurfaceData.c using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 625.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/native/sun/windows/awt_BitmapUtil.cpp openjdk/jdk/src/windows/native/sun/windows/awt_BitmapUtil.cpp
|--- openjdk.orig/jdk/src/windows/native/sun/windows/awt_BitmapUtil.cpp	2011-01-07 21:33:08.000000000 +0000
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_BitmapUtil.cpp	2011-05-18 16:12:18.112792526 +0100
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_BitmapUtil.cpp using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 28.
Hunk #3 succeeded at 153.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/native/sun/windows/awt_BitmapUtil.h openjdk/jdk/src/windows/native/sun/windows/awt_BitmapUtil.h
|--- openjdk.orig/jdk/src/windows/native/sun/windows/awt_BitmapUtil.h	2011-01-07 21:33:08.000000000 +0000
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_BitmapUtil.h	2011-05-18 16:12:18.112792526 +0100
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_BitmapUtil.h using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 45.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/native/sun/windows/awt_Component.cpp openjdk/jdk/src/windows/native/sun/windows/awt_Component.cpp
|--- openjdk.orig/jdk/src/windows/native/sun/windows/awt_Component.cpp	2011-05-18 15:58:49.000000000 +0100
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_Component.cpp	2011-05-18 16:12:18.112792526 +0100
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_Component.cpp using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 221.
Hunk #3 succeeded at 4697.
Hunk #4 succeeded at 6298 (offset 6 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/native/sun/windows/awt_Component.h openjdk/jdk/src/windows/native/sun/windows/awt_Component.h
|--- openjdk.orig/jdk/src/windows/native/sun/windows/awt_Component.h	2011-05-18 15:58:49.000000000 +0100
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_Component.h	2011-05-18 16:12:18.120792659 +0100
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_Component.h using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 422.
Hunk #3 succeeded at 711.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/native/sun/windows/awt_Window.cpp openjdk/jdk/src/windows/native/sun/windows/awt_Window.cpp
|--- openjdk.orig/jdk/src/windows/native/sun/windows/awt_Window.cpp	2011-05-18 15:58:49.000000000 +0100
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_Window.cpp	2011-05-18 16:12:18.120792659 +0100
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_Window.cpp using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 25.
Hunk #3 succeeded at 89.
Hunk #4 succeeded at 97.
Hunk #5 succeeded at 113.
Hunk #6 succeeded at 179 (offset -3 lines).
Hunk #7 succeeded at 1889 (offset -4 lines).
Hunk #8 succeeded at 2272 (offset -3 lines).
Hunk #9 succeeded at 2787 (offset -4 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/native/sun/windows/awt_Window.h openjdk/jdk/src/windows/native/sun/windows/awt_Window.h
|--- openjdk.orig/jdk/src/windows/native/sun/windows/awt_Window.h	2011-05-18 15:58:49.000000000 +0100
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_Window.h	2011-05-18 16:12:18.120792659 +0100
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_Window.h using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 182 (offset -6 lines).
Hunk #3 succeeded at 207 (offset -6 lines).
Hunk #4 succeeded at 234 (offset -6 lines).
Hunk #5 succeeded at 268 (offset -6 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/test/com/sun/awt/Translucency/TranslucentJAppletTest/TranslucentJAppletTest.java openjdk/jdk/test/com/sun/awt/Translucency/TranslucentJAppletTest/TranslucentJAppletTest.java
|--- openjdk.orig/jdk/test/com/sun/awt/Translucency/TranslucentJAppletTest/TranslucentJAppletTest.java	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/test/com/sun/awt/Translucency/TranslucentJAppletTest/TranslucentJAppletTest.java	2011-05-18 16:12:18.120792659 +0100
--------------------------
(Creating file openjdk/jdk/test/com/sun/awt/Translucency/TranslucentJAppletTest/TranslucentJAppletTest.java...)
Patching file openjdk/jdk/test/com/sun/awt/Translucency/TranslucentJAppletTest/TranslucentJAppletTest.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.form openjdk/jdk/test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.form
|--- openjdk.orig/jdk/test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.form	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.form	2011-05-18 16:12:18.120792659 +0100
--------------------------
(Creating file openjdk/jdk/test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.form...)
Patching file openjdk/jdk/test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.form using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.java openjdk/jdk/test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.java
|--- openjdk.orig/jdk/test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.java	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.java	2011-05-18 16:12:18.120792659 +0100
--------------------------
(Creating file openjdk/jdk/test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.java...)
Patching file openjdk/jdk/test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TranslucentShapedFrameTest.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TSFrame.java openjdk/jdk/test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TSFrame.java
|--- openjdk.orig/jdk/test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TSFrame.java	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TSFrame.java	2011-05-18 16:12:18.120792659 +0100
--------------------------
(Creating file openjdk/jdk/test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TSFrame.java...)
Patching file openjdk/jdk/test/com/sun/awt/Translucency/TranslucentShapedFrameTest/TSFrame.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/test/com/sun/awt/Translucency/WindowOpacity.java openjdk/jdk/test/com/sun/awt/Translucency/WindowOpacity.java
|--- openjdk.orig/jdk/test/com/sun/awt/Translucency/WindowOpacity.java	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/test/com/sun/awt/Translucency/WindowOpacity.java	2011-05-18 16:12:18.120792659 +0100
--------------------------
(Creating file openjdk/jdk/test/com/sun/awt/Translucency/WindowOpacity.java...)
Patching file openjdk/jdk/test/com/sun/awt/Translucency/WindowOpacity.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/test/sun/java2d/pipe/RegionOps.java openjdk/jdk/test/sun/java2d/pipe/RegionOps.java
|--- openjdk.orig/jdk/test/sun/java2d/pipe/RegionOps.java	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/test/sun/java2d/pipe/RegionOps.java	2011-05-18 16:12:18.120792659 +0100
--------------------------
(Creating file openjdk/jdk/test/sun/java2d/pipe/RegionOps.java...)
Patching file openjdk/jdk/test/sun/java2d/pipe/RegionOps.java using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/security/20120214/7112642.patch
Applying patches/security/20120214/7112642.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User bagiras
|# Date 1322689157 28800
|# Node ID 17eb322778160cc1463875e2b429211cf7966997
|# Parent  42706fbe23df228d55c454d0fbf8c3fb36fc4bc6
|7112642: Incorrect checking for graphics rendering object
|Reviewed-by: art, bae, flar, prr
|
|diff --git a/src/share/classes/sun/java2d/SunGraphics2D.java b/src/share/classes/sun/java2d/SunGraphics2D.java
|--- openjdk/jdk/src/share/classes/sun/java2d/SunGraphics2D.java
|+++ openjdk/jdk/src/share/classes/sun/java2d/SunGraphics2D.java
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/SunGraphics2D.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 369 (offset -1 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/src/share/classes/sun/java2d/opengl/OGLRenderer.java b/src/share/classes/sun/java2d/opengl/OGLRenderer.java
|--- openjdk/jdk/src/share/classes/sun/java2d/opengl/OGLRenderer.java
|+++ openjdk/jdk/src/share/classes/sun/java2d/opengl/OGLRenderer.java
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/opengl/OGLRenderer.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 27.
Hunk #3 succeeded at 47.
Hunk #4 succeeded at 61.
Hunk #5 succeeded at 80.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/src/share/classes/sun/java2d/pipe/BufferedContext.java b/src/share/classes/sun/java2d/pipe/BufferedContext.java
|--- openjdk/jdk/src/share/classes/sun/java2d/pipe/BufferedContext.java
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/BufferedContext.java
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/BufferedContext.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 110 (offset -1 lines).
Hunk #3 succeeded at 135 (offset -1 lines).
Hunk #4 succeeded at 162 (offset -1 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/src/windows/classes/sun/java2d/d3d/D3DRenderer.java b/src/windows/classes/sun/java2d/d3d/D3DRenderer.java
|--- openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DRenderer.java
|+++ openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DRenderer.java
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DRenderer.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 27.
Hunk #3 succeeded at 48.
Hunk #4 succeeded at 62.
Hunk #5 succeeded at 81.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/src/windows/classes/sun/java2d/windows/GDIRenderer.java b/src/windows/classes/sun/java2d/windows/GDIRenderer.java
|--- openjdk/jdk/src/windows/classes/sun/java2d/windows/GDIRenderer.java
|+++ openjdk/jdk/src/windows/classes/sun/java2d/windows/GDIRenderer.java
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/java2d/windows/GDIRenderer.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 29.
Hunk #3 succeeded at 46.
Hunk #4 succeeded at 55.
Hunk #5 succeeded at 89.
Hunk #6 succeeded at 124.
Hunk #7 succeeded at 144.
Hunk #8 succeeded at 191.
Hunk #9 succeeded at 226.
Hunk #10 succeeded at 246.
Hunk #11 succeeded at 277.
Hunk #12 succeeded at 292.
Hunk #13 succeeded at 326.
Hunk #14 succeeded at 336.
Hunk #15 succeeded at 359.
Hunk #16 succeeded at 375.
Hunk #17 succeeded at 385.
Hunk #18 succeeded at 401.
Hunk #19 succeeded at 417.
Hunk #20 succeeded at 427.
Hunk #21 succeeded at 438.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/src/windows/native/sun/java2d/windows/GDIRenderer.cpp b/src/windows/native/sun/java2d/windows/GDIRenderer.cpp
|--- openjdk/jdk/src/windows/native/sun/java2d/windows/GDIRenderer.cpp
|+++ openjdk/jdk/src/windows/native/sun/java2d/windows/GDIRenderer.cpp
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/java2d/windows/GDIRenderer.cpp using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 119 (offset 2 lines).
Hunk #3 succeeded at 166 (offset 2 lines).
Hunk #4 succeeded at 211 (offset 2 lines).
Hunk #5 succeeded at 255 (offset 2 lines).
Hunk #6 succeeded at 293 (offset 2 lines).
Hunk #7 succeeded at 349 (offset 2 lines).
Hunk #8 succeeded at 414 (offset 2 lines).
Hunk #9 succeeded at 447 (offset 2 lines).
Hunk #10 succeeded at 490 (offset 2 lines).
Hunk #11 succeeded at 557 (offset 2 lines).
Hunk #12 succeeded at 617 (offset 2 lines).
Hunk #13 succeeded at 682 (offset 2 lines).
Hunk #14 succeeded at 865 (offset 2 lines).
done
Checking patches/openjdk/6769607-modal-hangs.patch
Applying patches/openjdk/6769607-modal-hangs.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User dcherepanov
|# Date 1234870023 -10800
|# Node ID 5453a374c1d5838bf924e27fcd790d4bd9cadb2a
|# Parent  03276203c39cd11758db94645f9173e04ae47c3a
|6769607: PIT : Modal frame hangs for a while for few seconds in 6u12 b01 pit build
|Reviewed-by: art, anthony
|
|diff -r 03276203c39c -r 5453a374c1d5 src/share/classes/java/awt/Window.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/Window.java	Tue Feb 17 10:42:12 2009 +0300
|+++ openjdk/jdk/src/share/classes/java/awt/Window.java	Tue Feb 17 14:27:03 2009 +0300
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/Window.java using Plan A...
Hunk #1 succeeded at 682 (offset -5 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 03276203c39c -r 5453a374c1d5 src/windows/native/sun/windows/awt_Dialog.cpp
|--- openjdk.orig/jdk/src/windows/native/sun/windows/awt_Dialog.cpp	Tue Feb 17 10:42:12 2009 +0300
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_Dialog.cpp	Tue Feb 17 14:27:03 2009 +0300
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_Dialog.cpp using Plan A...
Hunk #1 succeeded at 231 (offset 1 line).
Hunk #2 succeeded at 255 (offset 1 line).
Hunk #3 succeeded at 268 (offset 1 line).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 03276203c39c -r 5453a374c1d5 src/windows/native/sun/windows/awt_Dialog.h
|--- openjdk.orig/jdk/src/windows/native/sun/windows/awt_Dialog.h	Tue Feb 17 10:42:12 2009 +0300
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_Dialog.h	Tue Feb 17 14:27:03 2009 +0300
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_Dialog.h using Plan A...
Hunk #1 succeeded at 113.
Hmm...  Ignoring the trailing garbage.
done
Checking patches/openjdk/6791612-opengl-jni-fix.patch
Applying patches/openjdk/6791612-opengl-jni-fix.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User tdv
|# Date 1235684318 28800
|# Node ID 0c856354b66924ad99e106ad0b99b1d263ef2eab
|# Parent  ff2afd0551c97282f5bc0939eda439166bfa71b4
|6791612: OGLBat tests are failed in jdk 7 b42
|Reviewed-by: tdv
|Contributed-by: ceisserer <linuxhippy at gmail.com>
|
|diff -r ff2afd0551c9 -r 0c856354b669 make/sun/xawt/mapfile-vers
|--- openjdk-old/jdk/make/sun/xawt/mapfile-vers	2010-08-16 16:54:21.000000000 +0200
|+++ openjdk/jdk/make/sun/xawt/mapfile-vers	2010-08-16 16:54:21.000000000 +0200
--------------------------
Patching file openjdk/jdk/make/sun/xawt/mapfile-vers using Plan A...
Hunk #1 succeeded at 302.
done
Checking patches/openjdk/6755274-glgetstring-crash.patch
Applying patches/openjdk/6755274-glgetstring-crash.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User tdv
|# Date 1224602738 25200
|# Node ID 452c58b2f5334bb357f778e319b5dfffe7b4c696
|# Parent  665850610378a6e9a46b7df1ce04d4fc6edfd236
|6755274: 6u10b33 2d tests fails on sles10x64 with jvm crash
|Reviewed-by: campbell
|
|diff -r 665850610378 -r 452c58b2f533 src/solaris/classes/sun/java2d/opengl/GLXGraphicsConfig.java
|--- openjdk.old/jdk/src/solaris/classes/sun/java2d/opengl/GLXGraphicsConfig.java	2010-08-30 11:47:11.000000000 +0200
|+++ openjdk/jdk/src/solaris/classes/sun/java2d/opengl/GLXGraphicsConfig.java	2010-08-30 11:47:11.000000000 +0200
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/java2d/opengl/GLXGraphicsConfig.java using Plan A...
Hunk #1 succeeded at 120.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 665850610378 -r 452c58b2f533 src/windows/classes/sun/java2d/opengl/WGLGraphicsConfig.java
|--- openjdk-old/jdk/src/windows/classes/sun/java2d/opengl/WGLGraphicsConfig.java	2010-08-30 11:47:11.000000000 +0200
|+++ openjdk/jdk/src/windows/classes/sun/java2d/opengl/WGLGraphicsConfig.java	2010-08-30 11:47:11.000000000 +0200
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/java2d/opengl/WGLGraphicsConfig.java using Plan A...
Hunk #1 succeeded at 127.
done
Checking patches/openjdk/6984543-onscreen_rendering_resize_test.patch
Applying patches/openjdk/6984543-onscreen_rendering_resize_test.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User ptisnovs
|# Date 1284636320 -7200
|# Node ID 441e86ab3233112c3564210c7a669c295628a679
|# Parent  a248eb631aa22ab6f3a3487a679814940117dadc
|6984543: Test sun/java2d/DirectX/OnScreenRenderingResizeTest fails on GNOME
|Summary: Testcase correction.
|Reviewed-by: art
|
|diff -r a248eb631aa2 -r 441e86ab3233 test/sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java
|--- openjdk/jdk/test/sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest-old.java	2010-09-17 14:01:17.000000000 +0200
|+++ openjdk/jdk/test/sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java	2010-09-17 13:20:00.000000000 +0200
--------------------------
Patching file openjdk/jdk/test/sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java using Plan A...
Hunk #1 succeeded at 157.
Hunk #2 succeeded at 166.
done
Checking patches/openjdk/6693253-security_warning.patch
Applying patches/openjdk/6693253-security_warning.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User anthony
|# Date 1297956979 0
|# Node ID 2c9218aed28a5706c062eac8c5e7db1ec3dc9dfc
|# Parent  119b67260c33358c5a34dddf69b709b78b39e590
|6693253: Security Warning appearance requires enhancements
|6779717: A Window does not show applet security warning icon on X platforms
|6785058: Parent don't get the focus after dialog is closed if security warning is applied
|Summary: Forward-port from 6u10-6u14
|Reviewed-by: art, dcherepanov
|diff -Nru openjdk.orig/jdk/make/sun/awt/Depend.mak openjdk/jdk/make/sun/awt/Depend.mak
|--- openjdk.orig/jdk/make/sun/awt/Depend.mak	2011-01-20 23:54:06.000000000 +0000
|+++ openjdk/jdk/make/sun/awt/Depend.mak	2011-02-17 15:50:10.704058433 +0000
--------------------------
Patching file openjdk/jdk/make/sun/awt/Depend.mak using Plan A...
Hunk #1 succeeded at 71.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/sun/awt/FILES_c_windows.gmk openjdk/jdk/make/sun/awt/FILES_c_windows.gmk
|--- openjdk.orig/jdk/make/sun/awt/FILES_c_windows.gmk	2011-02-17 15:43:31.000000000 +0000
|+++ openjdk/jdk/make/sun/awt/FILES_c_windows.gmk	2011-02-17 15:50:10.712057805 +0000
--------------------------
Patching file openjdk/jdk/make/sun/awt/FILES_c_windows.gmk using Plan A...
Hunk #1 succeeded at 202.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/sun/awt/make.depend openjdk/jdk/make/sun/awt/make.depend
|--- openjdk.orig/jdk/make/sun/awt/make.depend	2011-02-17 15:43:31.000000000 +0000
|+++ openjdk/jdk/make/sun/awt/make.depend	2011-02-17 15:50:10.720057177 +0000
--------------------------
Patching file openjdk/jdk/make/sun/awt/make.depend using Plan A...
Hunk #1 succeeded at 14.
Hunk #2 succeeded at 166.
Hunk #3 succeeded at 216.
Hunk #4 succeeded at 238.
Hunk #5 succeeded at 268.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/sun/awt/Makefile openjdk/jdk/make/sun/awt/Makefile
|--- openjdk.orig/jdk/make/sun/awt/Makefile	2011-02-17 15:43:31.000000000 +0000
|+++ openjdk/jdk/make/sun/awt/Makefile	2011-02-17 15:50:10.712057805 +0000
--------------------------
Patching file openjdk/jdk/make/sun/awt/Makefile using Plan A...
Hunk #1 succeeded at 551.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/sun/awt/README openjdk/jdk/make/sun/awt/README
|--- openjdk.orig/jdk/make/sun/awt/README	2011-01-20 23:54:06.000000000 +0000
|+++ openjdk/jdk/make/sun/awt/README	2011-02-17 15:50:10.712057805 +0000
--------------------------
Patching file openjdk/jdk/make/sun/awt/README using Plan A...
Hunk #1 succeeded at 6.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/sun/xawt/FILES_c_unix.gmk openjdk/jdk/make/sun/xawt/FILES_c_unix.gmk
|--- openjdk.orig/jdk/make/sun/xawt/FILES_c_unix.gmk	2011-01-20 23:54:06.000000000 +0000
|+++ openjdk/jdk/make/sun/xawt/FILES_c_unix.gmk	2011-02-17 15:50:10.720057177 +0000
--------------------------
Patching file openjdk/jdk/make/sun/xawt/FILES_c_unix.gmk using Plan A...
Hunk #1 succeeded at 78.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/sun/xawt/Makefile openjdk/jdk/make/sun/xawt/Makefile
|--- openjdk.orig/jdk/make/sun/xawt/Makefile	2011-01-20 23:54:06.000000000 +0000
|+++ openjdk/jdk/make/sun/xawt/Makefile	2011-02-17 15:50:10.720057177 +0000
--------------------------
Patching file openjdk/jdk/make/sun/xawt/Makefile using Plan A...
Hunk #1 succeeded at 79.
Hunk #2 succeeded at 277.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/sun/xawt/mapfile-vers openjdk/jdk/make/sun/xawt/mapfile-vers
|--- openjdk.orig/jdk/make/sun/xawt/mapfile-vers	2011-02-17 15:43:31.000000000 +0000
|+++ openjdk/jdk/make/sun/xawt/mapfile-vers	2011-02-17 15:50:10.720057177 +0000
--------------------------
Patching file openjdk/jdk/make/sun/xawt/mapfile-vers using Plan A...
Hunk #1 succeeded at 93.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/classes/com/sun/awt/SecurityWarning.java openjdk/jdk/src/share/classes/com/sun/awt/SecurityWarning.java
|--- openjdk.orig/jdk/src/share/classes/com/sun/awt/SecurityWarning.java	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/src/share/classes/com/sun/awt/SecurityWarning.java	2011-02-17 15:50:10.720057177 +0000
--------------------------
(Creating file openjdk/jdk/src/share/classes/com/sun/awt/SecurityWarning.java...)
Patching file openjdk/jdk/src/share/classes/com/sun/awt/SecurityWarning.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/classes/java/awt/Component.java openjdk/jdk/src/share/classes/java/awt/Component.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/Component.java	2011-02-17 15:43:31.000000000 +0000
|+++ openjdk/jdk/src/share/classes/java/awt/Component.java	2011-02-17 15:50:10.724056863 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/Component.java using Plan A...
Hunk #1 succeeded at 855.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/classes/java/awt/peer/WindowPeer.java openjdk/jdk/src/share/classes/java/awt/peer/WindowPeer.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/peer/WindowPeer.java	2011-02-17 15:43:31.000000000 +0000
|+++ openjdk/jdk/src/share/classes/java/awt/peer/WindowPeer.java	2011-02-17 15:50:10.724056863 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/peer/WindowPeer.java using Plan A...
Hunk #1 succeeded at 67.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/classes/java/awt/Window.java openjdk/jdk/src/share/classes/java/awt/Window.java
|--- openjdk.orig/jdk/src/share/classes/java/awt/Window.java	2011-02-17 15:43:31.000000000 +0000
|+++ openjdk/jdk/src/share/classes/java/awt/Window.java	2011-02-17 15:50:10.724056863 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/Window.java using Plan A...
Hunk #1 succeeded at 26.
Hunk #2 succeeded at 327.
Hunk #3 succeeded at 2807.
Hunk #4 succeeded at 3486 (offset -2 lines).
Hunk #5 succeeded at 3531 (offset -2 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/classes/sun/awt/AWTAccessor.java openjdk/jdk/src/share/classes/sun/awt/AWTAccessor.java
|--- openjdk.orig/jdk/src/share/classes/sun/awt/AWTAccessor.java	2011-02-17 15:43:31.000000000 +0000
|+++ openjdk/jdk/src/share/classes/sun/awt/AWTAccessor.java	2011-02-17 15:50:40.725701922 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/awt/AWTAccessor.java using Plan A...
Hunk #1 succeeded at 88.
Hunk #2 succeeded at 129.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/classes/sun/awt/EmbeddedFrame.java openjdk/jdk/src/share/classes/sun/awt/EmbeddedFrame.java
|--- openjdk.orig/jdk/src/share/classes/sun/awt/EmbeddedFrame.java	2011-02-17 15:43:31.000000000 +0000
|+++ openjdk/jdk/src/share/classes/sun/awt/EmbeddedFrame.java	2011-02-17 15:50:10.724056863 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/awt/EmbeddedFrame.java using Plan A...
Hunk #1 succeeded at 586.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/InfoWindow.java openjdk/jdk/src/solaris/classes/sun/awt/X11/InfoWindow.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/InfoWindow.java	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/X11/InfoWindow.java	2011-02-17 15:50:10.724056863 +0000
--------------------------
(Creating file openjdk/jdk/src/solaris/classes/sun/awt/X11/InfoWindow.java...)
Patching file openjdk/jdk/src/solaris/classes/sun/awt/X11/InfoWindow.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/XDecoratedPeer.java openjdk/jdk/src/solaris/classes/sun/awt/X11/XDecoratedPeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/XDecoratedPeer.java	2011-01-20 23:54:40.000000000 +0000
|+++ openjdk/jdk/src/solaris/classes/sun/awt/X11/XDecoratedPeer.java	2011-02-17 15:50:10.724056863 +0000
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/X11/XDecoratedPeer.java using Plan A...
Hunk #1 succeeded at 451.
Hunk #2 succeeded at 812.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/XKeyboardFocusManagerPeer.java openjdk/jdk/src/solaris/classes/sun/awt/X11/XKeyboardFocusManagerPeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/XKeyboardFocusManagerPeer.java	2011-02-17 15:43:30.000000000 +0000
|+++ openjdk/jdk/src/solaris/classes/sun/awt/X11/XKeyboardFocusManagerPeer.java	2011-02-17 15:50:10.724056863 +0000
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/X11/XKeyboardFocusManagerPeer.java using Plan A...
Hunk #1 succeeded at 62.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/XlibWrapper.java openjdk/jdk/src/solaris/classes/sun/awt/X11/XlibWrapper.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/XlibWrapper.java	2011-01-20 23:54:40.000000000 +0000
|+++ openjdk/jdk/src/solaris/classes/sun/awt/X11/XlibWrapper.java	2011-02-17 15:50:10.728056549 +0000
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/X11/XlibWrapper.java using Plan A...
Hunk #1 succeeded at 157.
Hunk #2 succeeded at 535.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/XNETProtocol.java openjdk/jdk/src/solaris/classes/sun/awt/X11/XNETProtocol.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/XNETProtocol.java	2011-02-17 15:43:31.000000000 +0000
|+++ openjdk/jdk/src/solaris/classes/sun/awt/X11/XNETProtocol.java	2011-02-17 15:50:10.724056863 +0000
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/X11/XNETProtocol.java using Plan A...
Hunk #1 succeeded at 178.
Hunk #2 succeeded at 218.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/XTrayIconPeer.java openjdk/jdk/src/solaris/classes/sun/awt/X11/XTrayIconPeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/XTrayIconPeer.java	2011-01-20 23:54:40.000000000 +0000
|+++ openjdk/jdk/src/solaris/classes/sun/awt/X11/XTrayIconPeer.java	2011-02-17 15:50:10.724056863 +0000
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/X11/XTrayIconPeer.java using Plan A...
Hunk #1 succeeded at 41.
Hunk #2 succeeded at 266.
Hunk #3 succeeded at 311.
Hunk #4 succeeded at 400.
Hunk #5 succeeded at 414.
Hunk #6 succeeded at 493.
Hunk #7 succeeded at 549.
Hunk #8 succeeded at 628.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/XWarningWindow.java openjdk/jdk/src/solaris/classes/sun/awt/X11/XWarningWindow.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/XWarningWindow.java	2011-01-20 23:54:40.000000000 +0000
|+++ openjdk/jdk/src/solaris/classes/sun/awt/X11/XWarningWindow.java	2011-02-17 15:50:10.728056549 +0000
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/X11/XWarningWindow.java using Plan A...
Hunk #1 succeeded at 25.
Hunk #2 succeeded at 227.
Hunk #3 succeeded at 261.
Hunk #4 succeeded at 270.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/XWindow.java openjdk/jdk/src/solaris/classes/sun/awt/X11/XWindow.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/XWindow.java	2011-01-20 23:54:40.000000000 +0000
|+++ openjdk/jdk/src/solaris/classes/sun/awt/X11/XWindow.java	2011-02-17 15:50:10.728056549 +0000
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/X11/XWindow.java using Plan A...
Hunk #1 succeeded at 68.
Hunk #2 succeeded at 217.
Hunk #3 succeeded at 824.
Hunk #4 succeeded at 1163.
Hunk #5 succeeded at 1380.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/XWindowPeer.java openjdk/jdk/src/solaris/classes/sun/awt/X11/XWindowPeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/XWindowPeer.java	2011-02-17 15:43:31.000000000 +0000
|+++ openjdk/jdk/src/solaris/classes/sun/awt/X11/XWindowPeer.java	2011-02-17 15:50:10.728056549 +0000
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/X11/XWindowPeer.java using Plan A...
Hunk #1 succeeded at 66.
Hunk #2 succeeded at 87.
Hunk #3 succeeded at 136.
Hunk #4 succeeded at 184.
Hunk #5 succeeded at 237.
Hunk #6 succeeded at 518.
Hunk #7 succeeded at 549.
Hunk #8 succeeded at 766.
Hunk #9 succeeded at 780.
Hunk #10 succeeded at 1059.
Hunk #11 succeeded at 1091.
Hunk #12 succeeded at 1109.
Hunk #13 succeeded at 1218.
Hunk #14 succeeded at 1319.
Hunk #15 succeeded at 1333.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/XWM.java openjdk/jdk/src/solaris/classes/sun/awt/X11/XWM.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/X11/XWM.java	2011-01-20 23:54:40.000000000 +0000
|+++ openjdk/jdk/src/solaris/classes/sun/awt/X11/XWM.java	2011-02-17 15:50:10.724056863 +0000
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/X11/XWM.java using Plan A...
Hunk #1 succeeded at 889.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/utility/rect.h openjdk/jdk/src/solaris/native/sun/awt/utility/rect.h
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/utility/rect.h	2011-01-20 23:54:42.000000000 +0000
|+++ openjdk/jdk/src/solaris/native/sun/awt/utility/rect.h	2011-02-17 15:50:10.728056549 +0000
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/utility/rect.h using Plan A...
Hunk #1 succeeded at 43.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/xawt/XlibWrapper.c openjdk/jdk/src/solaris/native/sun/xawt/XlibWrapper.c
|--- openjdk.orig/jdk/src/solaris/native/sun/xawt/XlibWrapper.c	2011-02-17 15:43:30.000000000 +0000
|+++ openjdk/jdk/src/solaris/native/sun/xawt/XlibWrapper.c	2011-02-17 15:50:10.728056549 +0000
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/xawt/XlibWrapper.c using Plan A...
Hunk #1 succeeded at 42.
Hunk #2 succeeded at 306.
Hunk #3 succeeded at 1975.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/classes/sun/awt/windows/WWindowPeer.java openjdk/jdk/src/windows/classes/sun/awt/windows/WWindowPeer.java
|--- openjdk.orig/jdk/src/windows/classes/sun/awt/windows/WWindowPeer.java	2011-02-17 15:43:31.000000000 +0000
|+++ openjdk/jdk/src/windows/classes/sun/awt/windows/WWindowPeer.java	2011-02-17 15:50:10.728056549 +0000
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/awt/windows/WWindowPeer.java using Plan A...
Hunk #1 succeeded at 499.
Hunk #2 succeeded at 511.
Hunk #3 succeeded at 539.
Hunk #4 succeeded at 553.
Hunk #5 succeeded at 561.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/native/sun/windows/awt_Component.cpp openjdk/jdk/src/windows/native/sun/windows/awt_Component.cpp
|--- openjdk.orig/jdk/src/windows/native/sun/windows/awt_Component.cpp	2011-02-17 15:43:31.000000000 +0000
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_Component.cpp	2011-02-17 15:50:10.728056549 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_Component.cpp using Plan A...
Hunk #1 succeeded at 282.
Hunk #2 succeeded at 604.
Hunk #3 succeeded at 4794.
Hunk #4 succeeded at 4894.
Hunk #5 succeeded at 6371 (offset 6 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/native/sun/windows/awt_Component.h openjdk/jdk/src/windows/native/sun/windows/awt_Component.h
|--- openjdk.orig/jdk/src/windows/native/sun/windows/awt_Component.h	2011-02-17 15:43:31.000000000 +0000
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_Component.h	2011-02-17 15:50:10.732056235 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_Component.h using Plan A...
Hunk #1 succeeded at 127.
Hunk #2 succeeded at 671.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/native/sun/windows/awt_Dialog.cpp openjdk/jdk/src/windows/native/sun/windows/awt_Dialog.cpp
|--- openjdk.orig/jdk/src/windows/native/sun/windows/awt_Dialog.cpp	2011-01-20 23:54:44.000000000 +0000
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_Dialog.cpp	2011-02-17 15:50:10.732056235 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_Dialog.cpp using Plan A...
Hunk #1 succeeded at 311 (offset 1 line).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/native/sun/windows/awt_Dialog.h openjdk/jdk/src/windows/native/sun/windows/awt_Dialog.h
|--- openjdk.orig/jdk/src/windows/native/sun/windows/awt_Dialog.h	2011-01-20 23:54:44.000000000 +0000
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_Dialog.h	2011-02-17 15:50:10.732056235 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_Dialog.h using Plan A...
Hunk #1 succeeded at 76.
Hunk #2 succeeded at 132 (offset 3 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/native/sun/windows/awt_Frame.cpp openjdk/jdk/src/windows/native/sun/windows/awt_Frame.cpp
|--- openjdk.orig/jdk/src/windows/native/sun/windows/awt_Frame.cpp	2011-01-20 23:54:44.000000000 +0000
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_Frame.cpp	2011-02-17 15:50:10.732056235 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_Frame.cpp using Plan A...
Hunk #1 succeeded at 551.
Hunk #2 succeeded at 787.
Hunk #3 succeeded at 879.
Hunk #4 succeeded at 922.
Hunk #5 succeeded at 931.
Hunk #6 succeeded at 943.
Hunk #7 succeeded at 1137.
Hunk #8 succeeded at 1165.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/native/sun/windows/awt_Frame.h openjdk/jdk/src/windows/native/sun/windows/awt_Frame.h
|--- openjdk.orig/jdk/src/windows/native/sun/windows/awt_Frame.h	2011-01-20 23:54:44.000000000 +0000
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_Frame.h	2011-02-17 15:50:10.732056235 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_Frame.h using Plan A...
Hunk #1 succeeded at 108.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/native/sun/windows/awt.rc openjdk/jdk/src/windows/native/sun/windows/awt.rc
|--- openjdk.orig/jdk/src/windows/native/sun/windows/awt.rc	2011-01-20 23:54:44.000000000 +0000
|+++ openjdk/jdk/src/windows/native/sun/windows/awt.rc	2011-02-17 15:50:10.728056549 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt.rc using Plan A...
Hunk #1 succeeded at 35.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/native/sun/windows/awt_Toolkit.cpp openjdk/jdk/src/windows/native/sun/windows/awt_Toolkit.cpp
|--- openjdk.orig/jdk/src/windows/native/sun/windows/awt_Toolkit.cpp	2011-02-17 15:43:31.000000000 +0000
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_Toolkit.cpp	2011-02-17 15:50:10.732056235 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_Toolkit.cpp using Plan A...
Hunk #1 succeeded at 56.
Hunk #2 succeeded at 335.
Hunk #3 succeeded at 485.
Hunk #4 succeeded at 959.
Hunk #5 succeeded at 1462.
Hunk #6 succeeded at 1587.
Hunk #7 succeeded at 1958.
Hunk #8 succeeded at 1969.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/native/sun/windows/awt_Toolkit.h openjdk/jdk/src/windows/native/sun/windows/awt_Toolkit.h
|--- openjdk.orig/jdk/src/windows/native/sun/windows/awt_Toolkit.h	2011-01-20 23:54:44.000000000 +0000
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_Toolkit.h	2011-02-17 15:50:10.732056235 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_Toolkit.h using Plan A...
Hunk #1 succeeded at 244.
Hunk #2 succeeded at 347.
Hunk #3 succeeded at 427.
Hunk #4 succeeded at 464.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp openjdk/jdk/src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp
|--- openjdk.orig/jdk/src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp	2011-02-17 15:43:31.000000000 +0000
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp	2011-02-17 15:50:10.732056235 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp using Plan A...
Hunk #1 succeeded at 31.
Hunk #2 succeeded at 92.
Hunk #3 succeeded at 105.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/native/sun/windows/awt_Window.cpp openjdk/jdk/src/windows/native/sun/windows/awt_Window.cpp
|--- openjdk.orig/jdk/src/windows/native/sun/windows/awt_Window.cpp	2011-02-17 15:43:31.000000000 +0000
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_Window.cpp	2011-02-17 15:50:10.732056235 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_Window.cpp using Plan A...
Hunk #1 succeeded at 30.
Hunk #2 succeeded at 39.
Hunk #3 succeeded at 132.
Hunk #4 succeeded at 145 with fuzz 2.
Hunk #5 succeeded at 153 (offset -3 lines).
Hunk #6 succeeded at 196 (offset -3 lines).
Hunk #7 succeeded at 261 (offset -1 lines).
Hunk #8 succeeded at 356 (offset -3 lines).
Hunk #9 succeeded at 411 (offset -1 lines).
Hunk #10 succeeded at 1302 (offset -3 lines).
Hunk #11 succeeded at 1541 (offset -1 lines).
Hunk #12 succeeded at 1597 (offset -3 lines).
Hunk #13 succeeded at 1701 (offset -1 lines).
Hunk #14 succeeded at 1766 (offset -3 lines).
Hunk #15 succeeded at 2005 (offset -4 lines).
Hunk #16 succeeded at 2898 (offset -3 lines).
Hunk #17 succeeded at 3432 (offset -4 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/native/sun/windows/awt_Window.h openjdk/jdk/src/windows/native/sun/windows/awt_Window.h
|--- openjdk.orig/jdk/src/windows/native/sun/windows/awt_Window.h	2011-02-17 15:43:31.000000000 +0000
|+++ openjdk/jdk/src/windows/native/sun/windows/awt_Window.h	2011-02-17 15:50:10.732056235 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/awt_Window.h using Plan A...
Hunk #1 succeeded at 56 with fuzz 2 (offset -1 lines).
Hunk #2 succeeded at 66 (offset -5 lines).
Hunk #3 succeeded at 162 (offset -1 lines).
Hunk #4 succeeded at 177 (offset -5 lines).
Hunk #5 succeeded at 222 (offset -1 lines).
Hunk #6 succeeded at 275 (offset -5 lines).
Hunk #7 succeeded at 343 (offset -1 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/native/sun/windows/ComCtl32Util.cpp openjdk/jdk/src/windows/native/sun/windows/ComCtl32Util.cpp
|--- openjdk.orig/jdk/src/windows/native/sun/windows/ComCtl32Util.cpp	2011-01-20 23:54:44.000000000 +0000
|+++ openjdk/jdk/src/windows/native/sun/windows/ComCtl32Util.cpp	2011-02-17 15:50:10.728056549 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/ComCtl32Util.cpp using Plan A...
Hunk #1 succeeded at 32.
Hunk #2 succeeded at 52.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/native/sun/windows/ComCtl32Util.h openjdk/jdk/src/windows/native/sun/windows/ComCtl32Util.h
|--- openjdk.orig/jdk/src/windows/native/sun/windows/ComCtl32Util.h	2011-01-20 23:54:44.000000000 +0000
|+++ openjdk/jdk/src/windows/native/sun/windows/ComCtl32Util.h	2011-02-17 15:50:10.728056549 +0000
--------------------------
Patching file openjdk/jdk/src/windows/native/sun/windows/ComCtl32Util.h using Plan A...
Hunk #1 succeeded at 63.
Hunk #2 succeeded at 87.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/native/sun/windows/DllUtil.cpp openjdk/jdk/src/windows/native/sun/windows/DllUtil.cpp
|--- openjdk.orig/jdk/src/windows/native/sun/windows/DllUtil.cpp	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/src/windows/native/sun/windows/DllUtil.cpp	2011-02-17 15:50:10.728056549 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/windows/DllUtil.cpp...)
Patching file openjdk/jdk/src/windows/native/sun/windows/DllUtil.cpp using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/windows/native/sun/windows/DllUtil.h openjdk/jdk/src/windows/native/sun/windows/DllUtil.h
|--- openjdk.orig/jdk/src/windows/native/sun/windows/DllUtil.h	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/src/windows/native/sun/windows/DllUtil.h	2011-02-17 15:50:10.728056549 +0000
--------------------------
(Creating file openjdk/jdk/src/windows/native/sun/windows/DllUtil.h...)
Patching file openjdk/jdk/src/windows/native/sun/windows/DllUtil.h using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/test/java/awt/Focus/CloseDialogActivateOwnerTest/CloseDialogActivateOwnerTest.java openjdk/jdk/test/java/awt/Focus/CloseDialogActivateOwnerTest/CloseDialogActivateOwnerTest.java
|--- openjdk.orig/jdk/test/java/awt/Focus/CloseDialogActivateOwnerTest/CloseDialogActivateOwnerTest.java	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/test/java/awt/Focus/CloseDialogActivateOwnerTest/CloseDialogActivateOwnerTest.java	2011-02-17 15:50:10.732056235 +0000
--------------------------
(Creating file openjdk/jdk/test/java/awt/Focus/CloseDialogActivateOwnerTest/CloseDialogActivateOwnerTest.java...)
Patching file openjdk/jdk/test/java/awt/Focus/CloseDialogActivateOwnerTest/CloseDialogActivateOwnerTest.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/test/java/awt/Focus/CloseDialogActivateOwnerTest/java.policy openjdk/jdk/test/java/awt/Focus/CloseDialogActivateOwnerTest/java.policy
|--- openjdk.orig/jdk/test/java/awt/Focus/CloseDialogActivateOwnerTest/java.policy	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/test/java/awt/Focus/CloseDialogActivateOwnerTest/java.policy	2011-02-17 15:50:10.732056235 +0000
--------------------------
(Creating file openjdk/jdk/test/java/awt/Focus/CloseDialogActivateOwnerTest/java.policy...)
Patching file openjdk/jdk/test/java/awt/Focus/CloseDialogActivateOwnerTest/java.policy using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/test/java/awt/Focus/OwnedWindowFocusIMECrashTest/OwnedWindowFocusIMECrashTest.java openjdk/jdk/test/java/awt/Focus/OwnedWindowFocusIMECrashTest/OwnedWindowFocusIMECrashTest.java
|--- openjdk.orig/jdk/test/java/awt/Focus/OwnedWindowFocusIMECrashTest/OwnedWindowFocusIMECrashTest.java	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/test/java/awt/Focus/OwnedWindowFocusIMECrashTest/OwnedWindowFocusIMECrashTest.java	2011-02-17 15:50:10.736055921 +0000
--------------------------
(Creating file openjdk/jdk/test/java/awt/Focus/OwnedWindowFocusIMECrashTest/OwnedWindowFocusIMECrashTest.java...)
Patching file openjdk/jdk/test/java/awt/Focus/OwnedWindowFocusIMECrashTest/OwnedWindowFocusIMECrashTest.java using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/openjdk/6444769-windowwithwarningtest.patch
Applying patches/openjdk/6444769-windowwithwarningtest.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User andrew
|# Date 1292334667 0
|# Node ID ff5b73fcc2ac8d72c0df5d31b6210ecb73eb4391
|# Parent  3d243dc7441260f121db54cca6fbc99fec1e929a
|6444769: java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html fails
|Summary: Remove unneeded test
|Reviewed-by: anthony
|
|diff -r 3d243dc74412 -r ff5b73fcc2ac test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html
|--- openjdk/jdk/test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html	Thu Feb 17 20:36:45 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 3d243dc74412 -r ff5b73fcc2ac test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java
|--- openjdk/jdk/test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java	Thu Feb 17 20:36:45 2011 +0000
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java using Plan A...
Hunk #1 succeeded at 0.
done
Checking patches/notice-safepoints.patch
Applying patches/notice-safepoints.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/hotspot/src/share/vm/interpreter/cppInterpreter.hpp	2009-04-30 23:21:47.000000000 +0000
|+++ openjdk/hotspot/src/share/vm/interpreter/cppInterpreter.hpp	2009-06-29 12:30:31.000000000 +0000
--------------------------
Patching file openjdk/hotspot/src/share/vm/interpreter/cppInterpreter.hpp using Plan A...
Hunk #1 succeeded at 65 (offset 5 lines).
done
Checking patches/parisc-opt.patch
Applying patches/parisc-opt.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/hotspot/make/linux/makefiles/product.make.orig	2008-12-10 19:02:31.000000000 +0100
|+++ openjdk/hotspot/make/linux/makefiles/product.make	2008-12-10 19:24:53.000000000 +0100
--------------------------
Patching file openjdk/hotspot/make/linux/makefiles/product.make using Plan A...
Hunk #1 succeeded at 25.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/hotspot/make/linux/makefiles/optimized.make.orig	2008-12-10 19:02:22.000000000 +0100
|+++ openjdk/hotspot/make/linux/makefiles/optimized.make	2008-12-10 19:24:24.000000000 +0100
--------------------------
Patching file openjdk/hotspot/make/linux/makefiles/optimized.make using Plan A...
Hunk #1 succeeded at 25.
done
Checking patches/lucene-crash.patch
Applying patches/lucene-crash.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 51798f0e554f test/compiler/6707044/LuceneCrash.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/hotspot/test/compiler/6707044/LuceneCrash.java	Thu Sep 25 21:55:28 2008 +0200
--------------------------
(Creating file openjdk/hotspot/test/compiler/6707044/LuceneCrash.java...)
Patching file openjdk/hotspot/test/compiler/6707044/LuceneCrash.java using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/version.patch
Applying patches/version.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 134c345baf84 make/common/shared/Defs.gmk
|--- openjdk.orig/jdk/make/common/shared/Defs.gmk	Thu Jun 18 11:12:13 2009 +0800
|+++ openjdk/jdk/make/common/shared/Defs.gmk	Sat Jan 09 00:26:19 2010 +0000
--------------------------
Patching file openjdk/jdk/make/common/shared/Defs.gmk using Plan A...
Hunk #1 succeeded at 194.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 134c345baf84 make/java/version/Makefile
|--- openjdk.orig/jdk/make/java/version/Makefile	Thu Jun 18 11:12:13 2009 +0800
|+++ openjdk/jdk/make/java/version/Makefile	Sat Jan 09 00:26:19 2010 +0000
--------------------------
Patching file openjdk/jdk/make/java/version/Makefile using Plan A...
Hunk #1 succeeded at 39.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 134c345baf84 src/share/classes/sun/misc/Version-template.java
|--- openjdk.orig/jdk/src/share/classes/sun/misc/Version-template.java	Thu Jun 18 11:12:13 2009 +0800
|+++ openjdk/jdk/src/share/classes/sun/misc/Version-template.java	Sat Jan 09 00:26:19 2010 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/misc/Version-template.java using Plan A...
Hunk #1 succeeded at 41.
Hunk #2 succeeded at 96.
done
Checking patches/version-hotspot.patch
Applying patches/version-hotspot.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/make/linux/makefiles/vm.make openjdk/hotspot/make/linux/makefiles/vm.make
|--- openjdk.orig/hotspot/make/linux/makefiles/vm.make	2010-01-18 22:58:55.000000000 +0000
|+++ openjdk/hotspot/make/linux/makefiles/vm.make	2010-01-20 17:26:22.000000000 +0000
--------------------------
Patching file openjdk/hotspot/make/linux/makefiles/vm.make using Plan A...
Hunk #1 succeeded at 91 (offset 5 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/src/share/vm/runtime/arguments.cpp openjdk/hotspot/src/share/vm/runtime/arguments.cpp
|--- openjdk.orig/hotspot/src/share/vm/runtime/arguments.cpp	2010-01-18 23:00:22.000000000 +0000
|+++ openjdk/hotspot/src/share/vm/runtime/arguments.cpp	2010-01-20 17:24:22.000000000 +0000
--------------------------
Patching file openjdk/hotspot/src/share/vm/runtime/arguments.cpp using Plan A...
Hunk #1 succeeded at 59 with fuzz 2 (offset 34 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/src/share/vm/utilities/vmError.cpp openjdk/hotspot/src/share/vm/utilities/vmError.cpp
|--- openjdk.orig/hotspot/src/share/vm/utilities/vmError.cpp	2010-01-18 22:56:40.000000000 +0000
|+++ openjdk/hotspot/src/share/vm/utilities/vmError.cpp	2010-01-20 17:25:15.000000000 +0000
--------------------------
Patching file openjdk/hotspot/src/share/vm/utilities/vmError.cpp using Plan A...
Hunk #1 succeeded at 185 (offset 20 lines).
Hunk #2 succeeded at 422 (offset 80 lines).
done
Checking patches/text-relocations.patch
Applying patches/text-relocations.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/make/linux/makefiles/gcc.make openjdk/hotspot/make/linux/makefiles/gcc.make
|--- openjdk.orig/hotspot/make/linux/makefiles/gcc.make	2011-01-25 22:57:24.000000000 +0000
|+++ openjdk/hotspot/make/linux/makefiles/gcc.make	2011-01-28 00:32:20.817556386 +0000
--------------------------
Patching file openjdk/hotspot/make/linux/makefiles/gcc.make using Plan A...
Hunk #1 succeeded at 58.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/make/linux/makefiles/rules.make openjdk/hotspot/make/linux/makefiles/rules.make
|--- openjdk.orig/hotspot/make/linux/makefiles/rules.make	2011-01-25 22:57:24.000000000 +0000
|+++ openjdk/hotspot/make/linux/makefiles/rules.make	2011-01-28 00:32:52.857892660 +0000
--------------------------
Patching file openjdk/hotspot/make/linux/makefiles/rules.make using Plan A...
Hunk #1 succeeded at 146.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/make/solaris/makefiles/rules.make openjdk/hotspot/make/solaris/makefiles/rules.make
|--- openjdk.orig/hotspot/make/solaris/makefiles/rules.make	2011-01-25 22:57:24.000000000 +0000
|+++ openjdk/hotspot/make/solaris/makefiles/rules.make	2011-01-28 00:33:15.158126725 +0000
--------------------------
Patching file openjdk/hotspot/make/solaris/makefiles/rules.make using Plan A...
Hunk #1 succeeded at 146.
done
Checking patches/openjdk/7043921-java_rmi_cgi.patch
Applying patches/openjdk/7043921-java_rmi_cgi.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User ohair
|# Date 1305210277 25200
|# Node ID 13fa9a0c628f58326cc376b7623a03b9d796136e
|# Parent  caed82420c5d01f5aaee5b15e8e37befc8db3d49
|7043921: generate java-rmi.cgi on 64 bit platform
|Reviewed-by: omajid, katleman
|
|diff -r caed82420c5d -r 13fa9a0c628f make/sun/rmi/rmi/Makefile
|--- openjdk/jdk/make/sun/rmi/rmi/Makefile	Wed May 11 14:12:50 2011 -0700
|+++ openjdk/jdk/make/sun/rmi/rmi/Makefile	Thu May 12 07:24:37 2011 -0700
--------------------------
Patching file openjdk/jdk/make/sun/rmi/rmi/Makefile using Plan A...
Hunk #1 succeeded at 85.
done
Checking patches/use-system-tzdata.patch
Applying patches/use-system-tzdata.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User andrew
|# Date 1257348405 0
|# Node ID d03acee39d3b283dbfe972ce9398ea1ce9cdd3fc
|# Parent  922421b1938a44633d22fd2a5a1e376a99bb9090
|6593486: (tz) RFE: support user-defined directory path to time zone data files
|Summary: Allow the timezone data directory to be changed by setting sun.timezone.dir
|
|diff -r 922421b1938a -r d03acee39d3b src/share/classes/sun/util/calendar/ZoneInfoFile.java
|--- openjdk.orig/jdk/src/share/classes/sun/util/calendar/ZoneInfoFile.java	Wed Nov 04 12:22:35 2009 +0000
|+++ openjdk/jdk/src/share/classes/sun/util/calendar/ZoneInfoFile.java	Wed Nov 04 15:26:45 2009 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/util/calendar/ZoneInfoFile.java using Plan A...
Hunk #1 succeeded at 25.
Hunk #2 succeeded at 40.
Hunk #3 succeeded at 476.
Hunk #4 succeeded at 1070.
done
Checking patches/headers.patch
Applying patches/headers.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdkold/jdk/make/tools/freetypecheck/Makefile	2008-01-04 18:20:30.000000000 -0500
|+++ openjdk/jdk/make/tools/freetypecheck/Makefile	2008-02-26 11:21:34.000000000 -0500
--------------------------
Patching file openjdk/jdk/make/tools/freetypecheck/Makefile using Plan A...
Hunk #1 succeeded at 61.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdkold/jdk/make/common/Defs.gmk	2008-01-04 18:20:29.000000000 -0500
|+++ openjdk/jdk/make/common/Defs.gmk	2008-02-26 11:21:49.000000000 -0500
--------------------------
Patching file openjdk/jdk/make/common/Defs.gmk using Plan A...
Hunk #1 succeeded at 164 (offset -73 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- oldopenjdk/jdk/make/sun/font/Makefile	2008-01-04 18:20:30.000000000 -0500
|+++ openjdk/jdk/make/sun/font/Makefile	2008-02-26 12:12:54.000000000 -0500
--------------------------
Patching file openjdk/jdk/make/sun/font/Makefile using Plan A...
Hunk #1 succeeded at 159 (offset -2 lines).
done
Checking patches/gcc-suffix.patch
Applying patches/gcc-suffix.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/jdk/make/common/shared/Compiler-gcc.gmk~	2007-08-02 09:17:53.000000000 +0200
|+++ openjdk/jdk/make/common/shared/Compiler-gcc.gmk	2007-08-08 16:30:52.857814544 +0200
--------------------------
Patching file openjdk/jdk/make/common/shared/Compiler-gcc.gmk using Plan A...
Hunk #1 succeeded at 58.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/corba/make/common/shared/Compiler-gcc.gmk~	2008-01-14 14:05:43.738465508 +0100
|+++ openjdk/corba/make/common/shared/Compiler-gcc.gmk	2008-01-14 14:19:33.640984398 +0100
--------------------------
Patching file openjdk/corba/make/common/shared/Compiler-gcc.gmk using Plan A...
Hunk #1 succeeded at 58 with fuzz 2.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/agent/src/os/linux/Makefile openjdk/hotspot/agent/src/os/linux/Makefile
|--- openjdk.orig/hotspot/agent/src/os/linux/Makefile	2011-01-25 22:57:24.000000000 +0000
|+++ openjdk/hotspot/agent/src/os/linux/Makefile	2011-01-28 00:43:20.632487152 +0000
--------------------------
Patching file openjdk/hotspot/agent/src/os/linux/Makefile using Plan A...
Hunk #1 succeeded at 23.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/make/linux/makefiles/gcc.make openjdk/hotspot/make/linux/makefiles/gcc.make
|--- openjdk.orig/hotspot/make/linux/makefiles/gcc.make	2011-01-28 00:35:53.000000000 +0000
|+++ openjdk/hotspot/make/linux/makefiles/gcc.make	2011-01-28 00:43:56.676866099 +0000
--------------------------
Patching file openjdk/hotspot/make/linux/makefiles/gcc.make using Plan A...
Hunk #1 succeeded at 28.
done
Checking patches/memory-limits.patch
Applying patches/memory-limits.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/src/cpu/x86/vm/c2_globals_x86.hpp openjdk/hotspot/src/cpu/x86/vm/c2_globals_x86.hpp
|--- openjdk.orig/hotspot/src/cpu/x86/vm/c2_globals_x86.hpp	2009-12-08 23:12:17.000000000 +0000
|+++ openjdk/hotspot/src/cpu/x86/vm/c2_globals_x86.hpp	2010-01-11 20:44:32.000000000 +0000
--------------------------
Patching file openjdk/hotspot/src/cpu/x86/vm/c2_globals_x86.hpp using Plan A...
Hunk #1 succeeded at 89 (offset -6 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/src/share/vm/runtime/globals.hpp openjdk/hotspot/src/share/vm/runtime/globals.hpp
|--- openjdk.orig/hotspot/src/share/vm/runtime/globals.hpp	2009-12-08 23:12:17.000000000 +0000
|+++ openjdk/hotspot/src/share/vm/runtime/globals.hpp	2010-01-11 20:45:17.000000000 +0000
--------------------------
Patching file openjdk/hotspot/src/share/vm/runtime/globals.hpp using Plan A...
Hunk #1 succeeded at 3039 (offset 230 lines).
done
Checking patches/libraries.patch
Applying patches/libraries.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk.old/jdk/make/sun/jpeg/Makefile	2007-10-12 03:54:08.000000000 -0400
|+++ openjdk/jdk/make/sun/jpeg/Makefile	2007-10-24 15:15:25.000000000 -0400
--------------------------
Patching file openjdk/jdk/make/sun/jpeg/Makefile using Plan A...
Hunk #1 succeeded at 68.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk.old/jdk/src/share/native/sun/awt/splashscreen/splashscreen_png.c	2007-10-12 04:03:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/splashscreen/splashscreen_png.c	2007-10-22 12:50:36.000000000 -0400
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/splashscreen/splashscreen_png.c using Plan A...
Hunk #1 succeeded at 25.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk.old/jdk/src/share/native/sun/awt/splashscreen/splashscreen_gif.c	2007-10-12 04:03:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/splashscreen/splashscreen_gif.c	2007-10-22 12:50:36.000000000 -0400
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/splashscreen/splashscreen_gif.c using Plan A...
Hunk #1 succeeded at 26.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk.old/jdk/src/share/native/java/util/zip/Adler32.c	2007-10-12 04:03:46.000000000 -0400
|+++ openjdk/jdk/src/share/native/java/util/zip/Adler32.c	2007-10-22 13:21:09.000000000 -0400
--------------------------
Patching file openjdk/jdk/src/share/native/java/util/zip/Adler32.c using Plan A...
Hunk #1 succeeded at 29.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk.old/jdk/src/share/native/java/util/zip/Deflater.c	2007-10-12 04:03:46.000000000 -0400
|+++ openjdk/jdk/src/share/native/java/util/zip/Deflater.c	2007-10-22 13:22:34.000000000 -0400
--------------------------
Patching file openjdk/jdk/src/share/native/java/util/zip/Deflater.c using Plan A...
Hunk #1 succeeded at 32.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk.old/jdk/src/share/native/java/util/zip/CRC32.c	2007-10-12 04:03:46.000000000 -0400
|+++ openjdk/jdk/src/share/native/java/util/zip/CRC32.c	2007-10-22 13:23:08.000000000 -0400
--------------------------
Patching file openjdk/jdk/src/share/native/java/util/zip/CRC32.c using Plan A...
Hunk #1 succeeded at 29.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk.old/jdk/make/common/Program.gmk	2007-10-12 03:54:05.000000000 -0400
|+++ openjdk/jdk/make/common/Program.gmk	2007-10-22 13:26:06.000000000 -0400
--------------------------
Patching file openjdk/jdk/make/common/Program.gmk using Plan A...
Hunk #1 succeeded at 85.
Hunk #2 succeeded at 229 with fuzz 2 (offset -22 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk.old/jdk/make/java/zip/Makefile	2007-10-12 03:54:05.000000000 -0400
|+++ openjdk/jdk/make/java/zip/Makefile	2007-10-22 13:27:01.000000000 -0400
--------------------------
Patching file openjdk/jdk/make/java/zip/Makefile using Plan A...
Hunk #1 succeeded at 30.
Hunk #2 succeeded at 70.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk.old/jdk/make/java/zip/FILES_c.gmk	2007-10-12 03:54:05.000000000 -0400
|+++ openjdk/jdk/make/java/zip/FILES_c.gmk	2007-10-22 13:52:53.000000000 -0400
--------------------------
Patching file openjdk/jdk/make/java/zip/FILES_c.gmk using Plan A...
Hunk #1 succeeded at 30.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk.old/jdk/src/share/native/java/util/zip/Inflater.c	2007-10-12 04:03:46.000000000 -0400
|+++ openjdk/jdk/src/share/native/java/util/zip/Inflater.c	2007-10-22 15:21:32.000000000 -0400
--------------------------
Patching file openjdk/jdk/src/share/native/java/util/zip/Inflater.c using Plan A...
Hunk #1 succeeded at 35.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk.old/jdk/src/share/native/java/util/zip/zip_util.c	2007-10-12 04:03:46.000000000 -0400
|+++ openjdk/jdk/src/share/native/java/util/zip/zip_util.c	2007-10-23 14:33:18.000000000 -0400
--------------------------
Patching file openjdk/jdk/src/share/native/java/util/zip/zip_util.c using Plan A...
Hunk #1 succeeded at 44.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk.old/jdk/make/sun/splashscreen/FILES_c.gmk	2007-10-12 03:54:08.000000000 -0400
|+++ openjdk/jdk/make/sun/splashscreen/FILES_c.gmk	2007-10-23 16:15:48.000000000 -0400
--------------------------
Patching file openjdk/jdk/make/sun/splashscreen/FILES_c.gmk using Plan A...
Hunk #1 succeeded at 30.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk.old/jdk/make/sun/splashscreen/Makefile	2007-10-12 03:54:08.000000000 -0400
|+++ openjdk/jdk/make/sun/splashscreen/Makefile	2007-10-23 16:20:24.000000000 -0400
--------------------------
Patching file openjdk/jdk/make/sun/splashscreen/Makefile using Plan A...
Hunk #1 succeeded at 59.
Hunk #2 succeeded at 76.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN openjdk.old/jdk/make/sun/jpeg/FILES_c.gmk openjdk/jdk/make/sun/jpeg/FILES_c.gmk
|--- openjdk.old/jdk/make/sun/jpeg/FILES_c.gmk	2007-10-12 03:54:08.000000000 -0400
|+++ openjdk/jdk/make/sun/jpeg/FILES_c.gmk	2007-10-23 17:13:59.000000000 -0400
--------------------------
Patching file openjdk/jdk/make/sun/jpeg/FILES_c.gmk using Plan A...
Hunk #1 succeeded at 25.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcapimin.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcapimin.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcapimin.c	2007-10-30 04:38:50.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcapimin.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcapimin.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcapistd.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcapistd.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcapistd.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcapistd.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcapistd.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jccoefct.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jccoefct.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jccoefct.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jccoefct.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jccoefct.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jccolor.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jccolor.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jccolor.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jccolor.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jccolor.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcdctmgr.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcdctmgr.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcdctmgr.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcdctmgr.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcdctmgr.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jchuff.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jchuff.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jchuff.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jchuff.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jchuff.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jchuff.h openjdk/jdk/src/share/native/sun/awt/image/jpeg/jchuff.h
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jchuff.h	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jchuff.h	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jchuff.h using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcinit.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcinit.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcinit.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcinit.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcinit.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcmainct.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcmainct.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcmainct.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcmainct.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcmainct.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcmarker.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcmarker.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcmarker.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcmarker.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcmarker.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcmaster.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcmaster.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcmaster.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcmaster.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcmaster.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcomapi.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcomapi.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcomapi.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcomapi.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcomapi.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jconfig.h openjdk/jdk/src/share/native/sun/awt/image/jpeg/jconfig.h
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jconfig.h	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jconfig.h	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jconfig.h using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcparam.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcparam.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcparam.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcparam.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcparam.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcphuff.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcphuff.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcphuff.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcphuff.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcphuff.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcprepct.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcprepct.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcprepct.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcprepct.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcprepct.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcsample.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcsample.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcsample.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcsample.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jcsample.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jctrans.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jctrans.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jctrans.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jctrans.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jctrans.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdapimin.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdapimin.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdapimin.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdapimin.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdapimin.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdapistd.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdapistd.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdapistd.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdapistd.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdapistd.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdcoefct.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdcoefct.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdcoefct.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdcoefct.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdcoefct.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdcolor.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdcolor.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdcolor.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdcolor.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdcolor.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdct.h openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdct.h
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdct.h	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdct.h	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdct.h using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jddctmgr.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jddctmgr.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jddctmgr.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jddctmgr.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jddctmgr.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdhuff.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdhuff.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdhuff.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdhuff.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdhuff.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdhuff.h openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdhuff.h
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdhuff.h	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdhuff.h	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdhuff.h using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdinput.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdinput.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdinput.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdinput.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdinput.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdmainct.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdmainct.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdmainct.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdmainct.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdmainct.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdmarker.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdmarker.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdmarker.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdmarker.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdmarker.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdmaster.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdmaster.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdmaster.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdmaster.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdmaster.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdmerge.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdmerge.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdmerge.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdmerge.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdmerge.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdphuff.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdphuff.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdphuff.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdphuff.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdphuff.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdpostct.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdpostct.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdpostct.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdpostct.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdpostct.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdsample.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdsample.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdsample.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdsample.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdsample.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdtrans.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdtrans.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdtrans.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdtrans.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jdtrans.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jerror.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jerror.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jerror.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jerror.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jerror.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jerror.h openjdk/jdk/src/share/native/sun/awt/image/jpeg/jerror.h
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jerror.h	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jerror.h	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jerror.h using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jfdctflt.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jfdctflt.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jfdctflt.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jfdctflt.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jfdctflt.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jfdctfst.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jfdctfst.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jfdctfst.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jfdctfst.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jfdctfst.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jfdctint.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jfdctint.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jfdctint.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jfdctint.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jfdctint.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jidctflt.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jidctflt.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jidctflt.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jidctflt.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jidctflt.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jidctfst.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jidctfst.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jidctfst.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jidctfst.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jidctfst.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jidctint.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jidctint.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jidctint.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jidctint.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jidctint.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jidctred.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jidctred.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jidctred.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jidctred.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jidctred.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jinclude.h openjdk/jdk/src/share/native/sun/awt/image/jpeg/jinclude.h
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jinclude.h	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jinclude.h	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jinclude.h using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jmemmgr.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jmemmgr.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jmemmgr.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jmemmgr.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jmemmgr.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jmemnobs.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jmemnobs.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jmemnobs.c	2007-10-30 04:38:51.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jmemnobs.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jmemnobs.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jmemsys.h openjdk/jdk/src/share/native/sun/awt/image/jpeg/jmemsys.h
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jmemsys.h	2007-10-30 04:38:52.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jmemsys.h	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jmemsys.h using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jmorecfg.h openjdk/jdk/src/share/native/sun/awt/image/jpeg/jmorecfg.h
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jmorecfg.h	2007-10-30 04:38:52.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jmorecfg.h	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jmorecfg.h using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jpegint.h openjdk/jdk/src/share/native/sun/awt/image/jpeg/jpegint.h
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jpegint.h	2007-10-30 04:38:52.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jpegint.h	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jpegint.h using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jpeglib.h openjdk/jdk/src/share/native/sun/awt/image/jpeg/jpeglib.h
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jpeglib.h	2007-10-30 04:38:52.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jpeglib.h	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jpeglib.h using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jquant1.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jquant1.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jquant1.c	2007-10-30 04:38:52.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jquant1.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jquant1.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jquant2.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jquant2.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jquant2.c	2007-10-30 04:38:52.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jquant2.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jquant2.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jutils.c openjdk/jdk/src/share/native/sun/awt/image/jpeg/jutils.c
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jutils.c	2007-10-30 04:38:52.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jutils.c	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jutils.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jversion.h openjdk/jdk/src/share/native/sun/awt/image/jpeg/jversion.h
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/jversion.h	2007-10-30 04:38:52.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jversion.h	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jversion.h using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/README openjdk/jdk/src/share/native/sun/awt/image/jpeg/README
|--- ..openjdk.old/openjdk/jdk/src/share/native/sun/awt/image/jpeg/README	2007-10-30 04:38:50.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/README	1969-12-31 19:00:00.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/README using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- ../oipenjdkb23/openjdk/jdk/src/share/native/sun/awt/splashscreen/splashscreen_jpeg.c	2007-10-30 04:38:55.000000000 -0400
|+++ openjdk/jdk/src/share/native/sun/awt/splashscreen/splashscreen_jpeg.c	2007-11-13 15:42:04.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/splashscreen/splashscreen_jpeg.c using Plan A...
Hunk #1 succeeded at 25.
Hunk #2 succeeded at 104.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- ../opienjdkb23/openjdk/jdk/make/com/sun/java/pack/Makefile	2007-10-30 04:39:48.000000000 -0400
|+++ openjdk/jdk/make/com/sun/java/pack/Makefile	2007-11-13 16:47:23.000000000 -0500
--------------------------
Patching file openjdk/jdk/make/com/sun/java/pack/Makefile using Plan A...
Hunk #1 succeeded at 64.
Hunk #2 succeeded at 100.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- penjdk6/jdk/make/java/jli/Makefile	2008-02-12 04:03:55.000000000 -0500
|+++ openjdk/jdk/make/java/jli/Makefile	2008-02-14 16:40:45.000000000 -0500
--------------------------
Patching file openjdk/jdk/make/java/jli/Makefile using Plan A...
Hunk #1 succeeded at 44.
Hunk #2 succeeded at 54.
Hunk #3 succeeded at 88.
Hunk #4 succeeded at 128.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk6/jdk/src/share/native/com/sun/java/util/jar/pack/defines.h	2008-02-12 04:08:07.000000000 -0500
|+++ openjdk/jdk/src/share/native/com/sun/java/util/jar/pack/defines.h	2008-02-14 16:57:24.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/com/sun/java/util/jar/pack/defines.h using Plan A...
Hunk #1 succeeded at 89 (offset 2 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdkold/jdk/src/share/native/sun/awt/image/jpeg/imageioJPEG.c	2008-02-12 04:08:13.000000000 -0500
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/imageioJPEG.c	2008-02-26 11:02:52.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/imageioJPEG.c using Plan A...
Hunk #1 succeeded at 52 (offset 1 line).
Hunk #2 succeeded at 78 (offset 1 line).
Hunk #3 succeeded at 676 (offset 3 lines).
Hunk #4 succeeded at 699 (offset 1 line).
Hunk #5 succeeded at 719 (offset 3 lines).
Hunk #6 succeeded at 757 (offset 5 lines).
Hunk #7 succeeded at 853 (offset 18 lines).
Hunk #8 succeeded at 865 (offset 9 lines).
Hunk #9 succeeded at 1422 (offset 18 lines).
Hunk #10 succeeded at 1500 (offset 9 lines).
Hunk #11 succeeded at 1526 (offset 18 lines).
Hunk #12 succeeded at 1539 (offset 9 lines).
Hunk #13 succeeded at 1666 (offset 18 lines).
Hunk #14 succeeded at 1778 (offset 9 lines).
Hunk #15 succeeded at 2027 (offset 34 lines).
Hunk #16 succeeded at 2014 (offset 9 lines).
Hunk #17 succeeded at 2047 (offset 34 lines).
Hunk #18 succeeded at 2038 (offset 9 lines).
Hunk #19 succeeded at 2076 (offset 34 lines).
Hunk #20 succeeded at 2113 (offset 16 lines).
Hunk #21 succeeded at 2157 (offset 34 lines).
Hunk #22 succeeded at 2187 (offset 16 lines).
Hunk #23 succeeded at 2411 (offset 34 lines).
Hunk #24 succeeded at 2543 (offset 16 lines).
Hunk #25 succeeded at 2636 (offset 34 lines).
Hunk #26 succeeded at 2635 (offset 16 lines).
Hunk #27 succeeded at 2762 (offset 34 lines).
Hunk #28 succeeded at 2759 (offset 16 lines).
Hunk #29 succeeded at 2941 (offset 42 lines).
Hunk #30 succeeded at 2954 (offset 16 lines).
Hunk #31 succeeded at 3005 (offset 42 lines).
Hunk #32 succeeded at 3021 (offset 16 lines).
Hunk #33 succeeded at 3113 (offset 44 lines).
Hunk #34 succeeded at 3094 (offset 16 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdkold/jdk/src/share/native/sun/awt/image/jpeg/jpegdecoder.c	2008-02-12 04:08:14.000000000 -0500
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/jpegdecoder.c	2008-02-26 11:01:37.000000000 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/jpegdecoder.c using Plan A...
Hunk #1 succeeded at 45.
Hunk #2 succeeded at 58.
Hunk #3 succeeded at 493.
Hunk #4 succeeded at 612.
Hunk #5 succeeded at 623.
Hunk #6 succeeded at 634.
Hunk #7 succeeded at 648.
Hunk #8 succeeded at 677.
Hunk #9 succeeded at 688.
Hunk #10 succeeded at 706.
Hunk #11 succeeded at 731.
Hunk #12 succeeded at 788.
Hunk #13 succeeded at 808.
done
Checking patches/jvmtiEnv.patch
Applying patches/jvmtiEnv.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/hotspot/src/share/vm/prims/jvmtiEnv.cpp.old	2009-02-26 17:18:35.000000000 +0000
|+++ openjdk/hotspot/src/share/vm/prims/jvmtiEnv.cpp	2009-02-26 17:16:59.000000000 +0000
--------------------------
Patching file openjdk/hotspot/src/share/vm/prims/jvmtiEnv.cpp using Plan A...
Hunk #1 succeeded at 2792 (offset 90 lines).
done
Checking patches/lcms.patch
Applying patches/lcms.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/native/sun/java2d/cmm/lcms/cmsxform.c openjdk/jdk/src/share/native/sun/java2d/cmm/lcms/cmsxform.c
|--- openjdk.orig/jdk/src/share/native/sun/java2d/cmm/lcms/cmsxform.c	2010-10-19 10:19:13.000000000 +0100
|+++ openjdk/jdk/src/share/native/sun/java2d/cmm/lcms/cmsxform.c	2010-10-19 13:02:07.580264578 +0100
--------------------------
Patching file openjdk/jdk/src/share/native/sun/java2d/cmm/lcms/cmsxform.c using Plan A...
Hunk #1 succeeded at 692.
Hunk #2 succeeded at 709.
Hunk #3 succeeded at 1351.
Hunk #4 succeeded at 1928.
done
Checking patches/print_lsb_release.patch
Applying patches/print_lsb_release.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/src/os/linux/vm/os_linux.cpp openjdk/hotspot/src/os/linux/vm/os_linux.cpp
|--- openjdk.orig/hotspot/src/os/linux/vm/os_linux.cpp	2010-09-01 01:23:45.000000000 +0100
|+++ openjdk/hotspot/src/os/linux/vm/os_linux.cpp	2010-09-19 14:41:48.029975576 +0100
--------------------------
Patching file openjdk/hotspot/src/os/linux/vm/os_linux.cpp using Plan A...
Hunk #1 succeeded at 1973 (offset 85 lines).
Hunk #2 succeeded at 2032 (offset 85 lines).
done
Checking patches/uname.patch
Applying patches/uname.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/jdk/make/common/shared/Platform.gmk.orig	2008-10-27 11:44:47.000000000 +0100
|+++ openjdk/jdk/make/common/shared/Platform.gmk	2008-10-27 11:52:17.000000000 +0100
--------------------------
Patching file openjdk/jdk/make/common/shared/Platform.gmk using Plan A...
Hunk #1 succeeded at 181 (offset -10 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/corba/make/common/shared/Platform.gmk.orig	2008-10-27 11:44:47.000000000 +0100
|+++ openjdk/corba/make/common/shared/Platform.gmk	2008-10-27 11:53:01.000000000 +0100
--------------------------
Patching file openjdk/corba/make/common/shared/Platform.gmk using Plan A...
Hunk #1 succeeded at 179 (offset -2 lines).
done
Checking patches/freetypeversion.patch
Applying patches/freetypeversion.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/jdk/make/common/shared/Platform.gmk.orig
|+++ openjdk/jdk/make/common/shared/Platform.gmk
--------------------------
Patching file openjdk/jdk/make/common/shared/Platform.gmk using Plan A...
Hunk #1 succeeded at 91 with fuzz 1 (offset -3 lines).
done
Checking patches/nomotif-6706121.patch
Applying patches/nomotif-6706121.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/sun/awt/FILES_c_unix.gmk openjdk/jdk/make/sun/awt/FILES_c_unix.gmk
|--- openjdk.orig/jdk/make/sun/awt/FILES_c_unix.gmk	2010-05-26 09:32:36.000000000 +0100
|+++ openjdk/jdk/make/sun/awt/FILES_c_unix.gmk	2010-05-26 13:11:21.000000000 +0100
--------------------------
Patching file openjdk/jdk/make/sun/awt/FILES_c_unix.gmk using Plan A...
Hunk #1 succeeded at 142.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/sun/awt/FILES_export_unix.gmk openjdk/jdk/make/sun/awt/FILES_export_unix.gmk
|--- openjdk.orig/jdk/make/sun/awt/FILES_export_unix.gmk	2010-05-26 09:32:36.000000000 +0100
|+++ openjdk/jdk/make/sun/awt/FILES_export_unix.gmk	2010-05-26 13:11:21.000000000 +0100
--------------------------
Patching file openjdk/jdk/make/sun/awt/FILES_export_unix.gmk using Plan A...
Hunk #1 succeeded at 60 (offset 3 lines).
Hunk #2 succeeded at 88 (offset 1 line).
Hunk #3 succeeded at 185 (offset 3 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/sun/awt/mapfile-mawt-vers openjdk/jdk/make/sun/awt/mapfile-mawt-vers
|--- openjdk.orig/jdk/make/sun/awt/mapfile-mawt-vers	2010-05-26 09:32:36.000000000 +0100
|+++ openjdk/jdk/make/sun/awt/mapfile-mawt-vers	2010-05-26 13:11:21.000000000 +0100
--------------------------
Patching file openjdk/jdk/make/sun/awt/mapfile-mawt-vers using Plan A...
Hunk #1 succeeded at 31.
Hunk #2 succeeded at 56.
Hunk #3 succeeded at 236.
Hunk #4 succeeded at 268.
Hunk #5 succeeded at 312 (offset 1 line).
Hunk #6 succeeded at 344 (offset 1 line).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/sun/awt/mapfile-vers-linux openjdk/jdk/make/sun/awt/mapfile-vers-linux
|--- openjdk.orig/jdk/make/sun/awt/mapfile-vers-linux	2010-05-26 09:32:36.000000000 +0100
|+++ openjdk/jdk/make/sun/awt/mapfile-vers-linux	2010-05-26 13:11:21.000000000 +0100
--------------------------
Patching file openjdk/jdk/make/sun/awt/mapfile-vers-linux using Plan A...
Hunk #1 succeeded at 169.
Hunk #2 succeeded at 188.
Hunk #3 succeeded at 356.
Hunk #4 succeeded at 386.
Hunk #5 succeeded at 442 (offset 1 line).
Hunk #6 succeeded at 503 (offset 1 line).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/sun/awt/mawt.gmk openjdk/jdk/make/sun/awt/mawt.gmk
|--- openjdk.orig/jdk/make/sun/awt/mawt.gmk	2010-05-26 09:32:36.000000000 +0100
|+++ openjdk/jdk/make/sun/awt/mawt.gmk	2010-05-26 13:11:21.000000000 +0100
--------------------------
Patching file openjdk/jdk/make/sun/awt/mawt.gmk using Plan A...
Hunk #1 succeeded at 28.
Hunk #2 succeeded at 44.
Hunk #3 succeeded at 81.
Hunk #4 succeeded at 116.
Hunk #5 succeeded at 166.
Hunk #6 succeeded at 196.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/sun/awt/mawt.gmk.orig openjdk/jdk/make/sun/awt/mawt.gmk.orig
|--- openjdk.orig/jdk/make/sun/awt/mawt.gmk.orig	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/make/sun/awt/mawt.gmk.orig	2010-05-26 09:32:36.000000000 +0100
--------------------------
Patching file openjdk/jdk/make/sun/awt/mawt.gmk.orig using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/sun/jawt/Makefile openjdk/jdk/make/sun/jawt/Makefile
|--- openjdk.orig/jdk/make/sun/jawt/Makefile	2010-05-26 09:32:36.000000000 +0100
|+++ openjdk/jdk/make/sun/jawt/Makefile	2010-05-26 13:11:21.000000000 +0100
--------------------------
Patching file openjdk/jdk/make/sun/jawt/Makefile using Plan A...
Hunk #1 succeeded at 99.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/sun/jawt/Makefile.orig openjdk/jdk/make/sun/jawt/Makefile.orig
|--- openjdk.orig/jdk/make/sun/jawt/Makefile.orig	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/make/sun/jawt/Makefile.orig	2010-05-26 09:32:36.000000000 +0100
--------------------------
Patching file openjdk/jdk/make/sun/jawt/Makefile.orig using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MButtonPeer.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MButtonPeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MButtonPeer.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MButtonPeer.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MButtonPeer.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MCanvasPeer.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MCanvasPeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MCanvasPeer.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MCanvasPeer.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MCanvasPeer.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MCheckboxMenuItemPeer.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MCheckboxMenuItemPeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MCheckboxMenuItemPeer.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MCheckboxMenuItemPeer.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MCheckboxMenuItemPeer.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MCheckboxPeer.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MCheckboxPeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MCheckboxPeer.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MCheckboxPeer.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MCheckboxPeer.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MChoicePeer.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MChoicePeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MChoicePeer.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MChoicePeer.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MChoicePeer.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MComponentPeer.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MComponentPeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MComponentPeer.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MComponentPeer.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MComponentPeer.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MCustomCursor.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MCustomCursor.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MCustomCursor.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MCustomCursor.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MCustomCursor.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MDataTransferer.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MDataTransferer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MDataTransferer.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MDataTransferer.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MDataTransferer.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MDialogPeer.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MDialogPeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MDialogPeer.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MDialogPeer.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MDialogPeer.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MDragSourceContextPeer.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MDragSourceContextPeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MDragSourceContextPeer.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MDragSourceContextPeer.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MDragSourceContextPeer.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MDropTargetContextPeer.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MDropTargetContextPeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MDropTargetContextPeer.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MDropTargetContextPeer.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MDropTargetContextPeer.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MEmbedCanvasPeer.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MEmbedCanvasPeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MEmbedCanvasPeer.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MEmbedCanvasPeer.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MEmbedCanvasPeer.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MEmbeddedFrame.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MEmbeddedFrame.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MEmbeddedFrame.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MEmbeddedFrame.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MEmbeddedFrame.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MEmbeddedFramePeer.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MEmbeddedFramePeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MEmbeddedFramePeer.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MEmbeddedFramePeer.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MEmbeddedFramePeer.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MFileDialogPeer.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MFileDialogPeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MFileDialogPeer.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MFileDialogPeer.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MFileDialogPeer.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MFramePeer.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MFramePeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MFramePeer.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MFramePeer.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MFramePeer.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MGlobalCursorManager.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MGlobalCursorManager.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MGlobalCursorManager.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MGlobalCursorManager.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MGlobalCursorManager.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MInputMethodControl.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MInputMethodControl.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MInputMethodControl.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MInputMethodControl.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MInputMethodControl.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MInputMethodDescriptor.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MInputMethodDescriptor.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MInputMethodDescriptor.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MInputMethodDescriptor.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MInputMethodDescriptor.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MInputMethod.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MInputMethod.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MInputMethod.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MInputMethod.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MInputMethod.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MLabelPeer.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MLabelPeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MLabelPeer.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MLabelPeer.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MLabelPeer.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MListPeer.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MListPeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MListPeer.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MListPeer.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MListPeer.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MMenuBarPeer.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MMenuBarPeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MMenuBarPeer.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MMenuBarPeer.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MMenuBarPeer.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MMenuItemPeer.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MMenuItemPeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MMenuItemPeer.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MMenuItemPeer.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MMenuItemPeer.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MMenuPeer.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MMenuPeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MMenuPeer.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MMenuPeer.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MMenuPeer.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MMouseDragGestureRecognizer.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MMouseDragGestureRecognizer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MMouseDragGestureRecognizer.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MMouseDragGestureRecognizer.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MMouseDragGestureRecognizer.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MPanelPeer.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MPanelPeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MPanelPeer.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MPanelPeer.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MPanelPeer.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MPopupMenuPeer.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MPopupMenuPeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MPopupMenuPeer.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MPopupMenuPeer.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MPopupMenuPeer.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MRobotPeer.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MRobotPeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MRobotPeer.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MRobotPeer.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MRobotPeer.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MScrollbarPeer.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MScrollbarPeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MScrollbarPeer.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MScrollbarPeer.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MScrollbarPeer.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MScrollPanePeer.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MScrollPanePeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MScrollPanePeer.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MScrollPanePeer.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MScrollPanePeer.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MTextAreaPeer.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MTextAreaPeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MTextAreaPeer.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MTextAreaPeer.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MTextAreaPeer.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MTextFieldPeer.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MTextFieldPeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MTextFieldPeer.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MTextFieldPeer.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MTextFieldPeer.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MToolkit.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MToolkit.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MToolkit.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MToolkit.java	2010-05-26 13:11:21.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MToolkit.java using Plan A...
Hunk #1 succeeded at 60.
Hunk #2 succeeded at 79.
Hunk #3 succeeded at 130.
Hunk #4 succeeded at 150.
Hunk #5 succeeded at 197.
Hunk #6 succeeded at 459.
Hunk #7 succeeded at 515.
Hunk #8 succeeded at 528.
Hunk #9 succeeded at 538.
Hunk #10 succeeded at 553.
Hunk #11 succeeded at 645.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MWindowPeer.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MWindowPeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MWindowPeer.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MWindowPeer.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MWindowPeer.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/X11Clipboard.java openjdk/jdk/src/solaris/classes/sun/awt/motif/X11Clipboard.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/X11Clipboard.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/X11Clipboard.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/X11Clipboard.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/X11DragSourceContextPeer.java openjdk/jdk/src/solaris/classes/sun/awt/motif/X11DragSourceContextPeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/X11DragSourceContextPeer.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/X11DragSourceContextPeer.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/X11DragSourceContextPeer.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/X11DropTargetContextPeer.java openjdk/jdk/src/solaris/classes/sun/awt/motif/X11DropTargetContextPeer.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/X11DropTargetContextPeer.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/X11DropTargetContextPeer.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/X11DropTargetContextPeer.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/X11SelectionHolder.java openjdk/jdk/src/solaris/classes/sun/awt/motif/X11SelectionHolder.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/X11SelectionHolder.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/X11SelectionHolder.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/X11SelectionHolder.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/X11Selection.java openjdk/jdk/src/solaris/classes/sun/awt/motif/X11Selection.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/X11Selection.java	2010-05-26 09:32:50.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/X11Selection.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/X11Selection.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_Button.c openjdk/jdk/src/solaris/native/sun/awt/awt_Button.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_Button.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_Button.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_Button.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_Canvas.c openjdk/jdk/src/solaris/native/sun/awt/awt_Canvas.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_Canvas.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_Canvas.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_Canvas.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_Checkbox.c openjdk/jdk/src/solaris/native/sun/awt/awt_Checkbox.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_Checkbox.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_Checkbox.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_Checkbox.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_Choice12.c openjdk/jdk/src/solaris/native/sun/awt/awt_Choice12.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_Choice12.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_Choice12.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_Choice12.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_Choice21.c openjdk/jdk/src/solaris/native/sun/awt/awt_Choice21.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_Choice21.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_Choice21.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_Choice21.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_Component.c openjdk/jdk/src/solaris/native/sun/awt/awt_Component.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_Component.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_Component.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_Component.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_Cursor.c openjdk/jdk/src/solaris/native/sun/awt/awt_Cursor.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_Cursor.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_Cursor.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_Cursor.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_DataTransferer.c openjdk/jdk/src/solaris/native/sun/awt/awt_DataTransferer.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_DataTransferer.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_DataTransferer.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_DataTransferer.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_DataTransferer.h openjdk/jdk/src/solaris/native/sun/awt/awt_DataTransferer.h
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_DataTransferer.h	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_DataTransferer.h	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_DataTransferer.h using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_dnd.c openjdk/jdk/src/solaris/native/sun/awt/awt_dnd.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_dnd.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_dnd.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_dnd.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_dnd_ds.c openjdk/jdk/src/solaris/native/sun/awt/awt_dnd_ds.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_dnd_ds.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_dnd_ds.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_dnd_ds.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_dnd_dt.c openjdk/jdk/src/solaris/native/sun/awt/awt_dnd_dt.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_dnd_dt.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_dnd_dt.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_dnd_dt.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_dnd.h openjdk/jdk/src/solaris/native/sun/awt/awt_dnd.h
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_dnd.h	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_dnd.h	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_dnd.h using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_DrawingSurface.c openjdk/jdk/src/solaris/native/sun/awt/awt_DrawingSurface.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_DrawingSurface.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_DrawingSurface.c	2010-05-26 13:11:21.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_DrawingSurface.c using Plan A...
Hunk #1 succeeded at 29.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_FileDialog.c openjdk/jdk/src/solaris/native/sun/awt/awt_FileDialog.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_FileDialog.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_FileDialog.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_FileDialog.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_GlobalCursorManager.c openjdk/jdk/src/solaris/native/sun/awt/awt_GlobalCursorManager.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_GlobalCursorManager.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_GlobalCursorManager.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_GlobalCursorManager.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_KeyboardFocusManager.c openjdk/jdk/src/solaris/native/sun/awt/awt_KeyboardFocusManager.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_KeyboardFocusManager.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_KeyboardFocusManager.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_KeyboardFocusManager.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_Label.c openjdk/jdk/src/solaris/native/sun/awt/awt_Label.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_Label.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_Label.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_Label.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_List.c openjdk/jdk/src/solaris/native/sun/awt/awt_List.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_List.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_List.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_List.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_MenuBar.c openjdk/jdk/src/solaris/native/sun/awt/awt_MenuBar.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_MenuBar.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_MenuBar.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_MenuBar.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_MenuBar.h openjdk/jdk/src/solaris/native/sun/awt/awt_MenuBar.h
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_MenuBar.h	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_MenuBar.h	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_MenuBar.h using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_Menu.c openjdk/jdk/src/solaris/native/sun/awt/awt_Menu.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_Menu.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_Menu.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_Menu.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_MenuComponent.c openjdk/jdk/src/solaris/native/sun/awt/awt_MenuComponent.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_MenuComponent.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_MenuComponent.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_MenuComponent.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_Menu.h openjdk/jdk/src/solaris/native/sun/awt/awt_Menu.h
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_Menu.h	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_Menu.h	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_Menu.h using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_MenuItem.c openjdk/jdk/src/solaris/native/sun/awt/awt_MenuItem.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_MenuItem.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_MenuItem.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_MenuItem.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_motif12.c openjdk/jdk/src/solaris/native/sun/awt/awt_motif12.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_motif12.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_motif12.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_motif12.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_motif21.c openjdk/jdk/src/solaris/native/sun/awt/awt_motif21.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_motif21.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_motif21.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_motif21.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_motif.c openjdk/jdk/src/solaris/native/sun/awt/awt_motif.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_motif.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_motif.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_motif.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_MToolkit.c openjdk/jdk/src/solaris/native/sun/awt/awt_MToolkit.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_MToolkit.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_MToolkit.c	2010-05-26 13:11:21.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_MToolkit.c using Plan A...
Hunk #1 succeeded at 48.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_p.h openjdk/jdk/src/solaris/native/sun/awt/awt_p.h
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_p.h	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_p.h	2010-05-26 13:11:21.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_p.h using Plan A...
Hunk #1 succeeded at 79.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_PopupMenu.c openjdk/jdk/src/solaris/native/sun/awt/awt_PopupMenu.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_PopupMenu.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_PopupMenu.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_PopupMenu.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_Robot.c openjdk/jdk/src/solaris/native/sun/awt/awt_Robot.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_Robot.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_Robot.c	2010-05-26 13:11:21.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_Robot.c using Plan A...
Hunk #1 succeeded at 204.
Hunk #2 succeeded at 226.
Hunk #3 succeeded at 289.
Hunk #4 succeeded at 309.
Hunk #5 succeeded at 327.
Hunk #6 succeeded at 349.
Hunk #7 succeeded at 373.
Hunk #8 succeeded at 397.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_Scrollbar.c openjdk/jdk/src/solaris/native/sun/awt/awt_Scrollbar.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_Scrollbar.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_Scrollbar.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_Scrollbar.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_ScrollPane.c openjdk/jdk/src/solaris/native/sun/awt/awt_ScrollPane.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_ScrollPane.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_ScrollPane.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_ScrollPane.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_Selection.c openjdk/jdk/src/solaris/native/sun/awt/awt_Selection.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_Selection.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_Selection.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_Selection.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_TextArea.c openjdk/jdk/src/solaris/native/sun/awt/awt_TextArea.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_TextArea.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_TextArea.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_TextArea.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_TextArea.h openjdk/jdk/src/solaris/native/sun/awt/awt_TextArea.h
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_TextArea.h	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_TextArea.h	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_TextArea.h using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_TextField.c openjdk/jdk/src/solaris/native/sun/awt/awt_TextField.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_TextField.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_TextField.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_TextField.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_TextField.h openjdk/jdk/src/solaris/native/sun/awt/awt_TextField.h
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_TextField.h	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_TextField.h	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_TextField.h using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_TopLevel.c openjdk/jdk/src/solaris/native/sun/awt/awt_TopLevel.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_TopLevel.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_TopLevel.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_TopLevel.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_xembed.c openjdk/jdk/src/solaris/native/sun/awt/awt_xembed.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_xembed.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_xembed.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_xembed.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_XmDnD.c openjdk/jdk/src/solaris/native/sun/awt/awt_XmDnD.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_XmDnD.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_XmDnD.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_XmDnD.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/awt_XmDnD.h openjdk/jdk/src/solaris/native/sun/awt/awt_XmDnD.h
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_XmDnD.h	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_XmDnD.h	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_XmDnD.h using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/canvas.c openjdk/jdk/src/solaris/native/sun/awt/canvas.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/canvas.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/canvas.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/canvas.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/cursor.c openjdk/jdk/src/solaris/native/sun/awt/cursor.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/cursor.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/cursor.c	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/cursor.c using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/initIDs.c openjdk/jdk/src/solaris/native/sun/awt/initIDs.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/initIDs.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/initIDs.c	2010-05-26 13:11:21.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/initIDs.c using Plan A...
Hunk #1 succeeded at 26.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/native/sun/awt/multi_font.c openjdk/jdk/src/solaris/native/sun/awt/multi_font.c
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/multi_font.c	2010-05-26 09:32:51.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/sun/awt/multi_font.c	2010-05-26 13:11:21.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/multi_font.c using Plan A...
Hunk #1 succeeded at 52.
Hunk #2 succeeded at 151.
done
Checking patches/nomotif.patch
Applying patches/nomotif.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/jdk/make/common/shared/Sanity.gmk~	2008-07-10 21:54:40.000000000 +0200
|+++ openjdk/jdk/make/common/shared/Sanity.gmk	2008-07-17 11:15:52.000000000 +0200
--------------------------
Patching file openjdk/jdk/make/common/shared/Sanity.gmk using Plan A...
Hunk #1 succeeded at 739 (offset -41 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/jdk/src/solaris/native/sun/awt/awt_util.c~	2008-07-10 21:58:43.000000000 +0200
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_util.c	2008-07-17 12:28:56.000000000 +0200
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_util.c using Plan A...
Hunk #1 succeeded at 49.
done
Checking patches/nomotif-mtoolkit.patch
Applying patches/nomotif-mtoolkit.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk.orig/jdk/src/solaris/native/sun/awt/awt_LoadLibrary.c	2009-11-23 13:06:29.271625283 +0000
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_LoadLibrary.c	2010-01-15 15:31:25.577635803 +0000
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_LoadLibrary.c using Plan A...
Hunk #1 succeeded at 81.
Hunk #2 succeeded at 105.
Hunk #3 succeeded at 114.
Hunk #4 succeeded at 132.
done
Checking patches/alpha-fixes.patch
Applying patches/alpha-fixes.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/agent/src/os/linux/Makefile openjdk/hotspot/agent/src/os/linux/Makefile
|--- openjdk.orig/hotspot/agent/src/os/linux/Makefile	2010-09-19 14:44:40.000000000 +0100
|+++ openjdk/hotspot/agent/src/os/linux/Makefile	2010-09-19 15:34:47.064793576 +0100
--------------------------
Patching file openjdk/hotspot/agent/src/os/linux/Makefile using Plan A...
Hunk #1 succeeded at 40.
Hunk #2 succeeded at 73.
done
Checking patches/alt-jar.patch
Applying patches/alt-jar.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk.orig/jdk/make/common/shared/Defs-java.gmk	2008-05-30 03:50:36.000000000 -0400
|+++ openjdk/jdk/make/common/shared/Defs-java.gmk	2008-08-06 11:18:26.000000000 -0400
--------------------------
Patching file openjdk/jdk/make/common/shared/Defs-java.gmk using Plan A...
Hunk #1 succeeded at 189 (offset 8 lines).
done
Checking patches/jdk-use-ssize_t.patch
Applying patches/jdk-use-ssize_t.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/jdk/src/solaris/hpi/native_threads/src/sys_api_td.c.old	2008-07-10 21:58:39.000000000 +0200
|+++ openjdk/jdk/src/solaris/hpi/native_threads/src/sys_api_td.c	2008-08-03 16:26:16.000000000 +0200
--------------------------
Patching file openjdk/jdk/src/solaris/hpi/native_threads/src/sys_api_td.c using Plan A...
Hunk #1 succeeded at 380.
Hunk #2 succeeded at 595.
done
Checking patches/use-idx_t.patch
Applying patches/use-idx_t.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/hotspot/src/share/vm/compiler/methodLiveness.cpp.orig	2008-12-20 18:59:01.000000000 +0100
|+++ openjdk/hotspot/src/share/vm/compiler/methodLiveness.cpp	2009-03-11 21:49:08.000000000 +0100
--------------------------
Patching file openjdk/hotspot/src/share/vm/compiler/methodLiveness.cpp using Plan A...
Hunk #1 succeeded at 473 (offset 5 lines).
Hunk #2 succeeded at 572 (offset 5 lines).
Hunk #3 succeeded at 993 (offset 1 line).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/hotspot/src/share/vm/utilities/bitMap.hpp.orig	2008-12-20 18:59:01.000000000 +0100
|+++ openjdk/hotspot/src/share/vm/utilities/bitMap.hpp	2009-03-11 21:48:18.000000000 +0100
--------------------------
Patching file openjdk/hotspot/src/share/vm/utilities/bitMap.hpp using Plan A...
Hunk #1 succeeded at 39 (offset 6 lines).
Hunk #2 succeeded at 79 (offset 6 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/hotspot/src/share/vm/utilities/bitMap.inline.hpp.orig	2008-12-20 18:59:01.000000000 +0100
|+++ openjdk/hotspot/src/share/vm/utilities/bitMap.inline.hpp	2009-03-11 21:48:18.000000000 +0100
--------------------------
Patching file openjdk/hotspot/src/share/vm/utilities/bitMap.inline.hpp using Plan A...
Hunk #1 succeeded at 52 (offset 17 lines).
Hunk #2 succeeded at 73 (offset 17 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp.orig	2008-12-20 18:59:01.000000000 +0100
|+++ openjdk/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp	2009-03-11 21:48:47.000000000 +0100
--------------------------
Patching file openjdk/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp using Plan A...
Hunk #1 succeeded at 43 (offset 14 lines).
Hunk #2 succeeded at 57 (offset 14 lines).
done
Checking patches/params-cast-size_t.patch
Applying patches/params-cast-size_t.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp openjdk/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
|--- openjdk.orig/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp	2011-01-25 22:57:24.000000000 +0000
|+++ openjdk/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp	2011-01-28 01:06:11.887088930 +0000
--------------------------
Patching file openjdk/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp using Plan A...
Hunk #1 succeeded at 2645.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp openjdk/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
|--- openjdk.orig/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp	2011-01-25 22:57:24.000000000 +0000
|+++ openjdk/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp	2011-01-28 01:06:11.891088974 +0000
--------------------------
Patching file openjdk/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp using Plan A...
Hunk #1 succeeded at 955.
Hunk #2 succeeded at 6238.
Hunk #3 succeeded at 6533.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp openjdk/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp
|--- openjdk.orig/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp	2011-01-28 00:50:00.000000000 +0000
|+++ openjdk/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp	2011-01-28 01:06:11.891088974 +0000
--------------------------
Patching file openjdk/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp using Plan A...
Hunk #1 succeeded at 471.
Hunk #2 succeeded at 575.
Hunk #3 succeeded at 3387 (offset 16 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp openjdk/hotspot/src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp
|--- openjdk.orig/hotspot/src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp	2011-01-25 22:57:24.000000000 +0000
|+++ openjdk/hotspot/src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp	2011-01-28 01:06:11.891088974 +0000
--------------------------
Patching file openjdk/hotspot/src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp using Plan A...
Hunk #1 succeeded at 1078 (offset 4 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp openjdk/hotspot/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
|--- openjdk.orig/hotspot/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp	2011-01-25 22:57:24.000000000 +0000
|+++ openjdk/hotspot/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp	2011-01-28 01:06:11.891088974 +0000
--------------------------
Patching file openjdk/hotspot/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp using Plan A...
Hunk #1 succeeded at 895.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp openjdk/hotspot/src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp
|--- openjdk.orig/hotspot/src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp	2011-01-25 22:57:24.000000000 +0000
|+++ openjdk/hotspot/src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp	2011-01-28 01:06:11.891088974 +0000
--------------------------
Patching file openjdk/hotspot/src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp using Plan A...
Hunk #1 succeeded at 69.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/src/share/vm/gc_implementation/parNew/parNewGeneration.cpp openjdk/hotspot/src/share/vm/gc_implementation/parNew/parNewGeneration.cpp
|--- openjdk.orig/hotspot/src/share/vm/gc_implementation/parNew/parNewGeneration.cpp	2011-01-25 22:57:24.000000000 +0000
|+++ openjdk/hotspot/src/share/vm/gc_implementation/parNew/parNewGeneration.cpp	2011-01-28 01:06:11.895089019 +0000
--------------------------
Patching file openjdk/hotspot/src/share/vm/gc_implementation/parNew/parNewGeneration.cpp using Plan A...
Hunk #1 succeeded at 188.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/src/share/vm/memory/collectorPolicy.cpp openjdk/hotspot/src/share/vm/memory/collectorPolicy.cpp
|--- openjdk.orig/hotspot/src/share/vm/memory/collectorPolicy.cpp	2011-01-25 22:57:24.000000000 +0000
|+++ openjdk/hotspot/src/share/vm/memory/collectorPolicy.cpp	2011-01-28 01:06:11.891088974 +0000
--------------------------
Patching file openjdk/hotspot/src/share/vm/memory/collectorPolicy.cpp using Plan A...
Hunk #1 succeeded at 328.
Hunk #2 succeeded at 355.
Hunk #3 succeeded at 363.
Hunk #4 succeeded at 421.
Hunk #5 succeeded at 452.
Hunk #6 succeeded at 466.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/src/share/vm/memory/threadLocalAllocBuffer.cpp openjdk/hotspot/src/share/vm/memory/threadLocalAllocBuffer.cpp
|--- openjdk.orig/hotspot/src/share/vm/memory/threadLocalAllocBuffer.cpp	2011-01-25 22:57:24.000000000 +0000
|+++ openjdk/hotspot/src/share/vm/memory/threadLocalAllocBuffer.cpp	2011-01-28 01:06:11.891088974 +0000
--------------------------
Patching file openjdk/hotspot/src/share/vm/memory/threadLocalAllocBuffer.cpp using Plan A...
Hunk #1 succeeded at 240.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/src/share/vm/oops/objArrayKlass.inline.hpp openjdk/hotspot/src/share/vm/oops/objArrayKlass.inline.hpp
|--- openjdk.orig/hotspot/src/share/vm/oops/objArrayKlass.inline.hpp	2011-01-25 22:57:24.000000000 +0000
|+++ openjdk/hotspot/src/share/vm/oops/objArrayKlass.inline.hpp	2011-01-28 01:06:11.891088974 +0000
--------------------------
Patching file openjdk/hotspot/src/share/vm/oops/objArrayKlass.inline.hpp using Plan A...
Hunk #1 succeeded at 46.
Hunk #2 succeeded at 80.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/src/share/vm/runtime/arguments.cpp openjdk/hotspot/src/share/vm/runtime/arguments.cpp
|--- openjdk.orig/hotspot/src/share/vm/runtime/arguments.cpp	2011-01-28 00:49:59.000000000 +0000
|+++ openjdk/hotspot/src/share/vm/runtime/arguments.cpp	2011-01-28 01:06:11.891088974 +0000
--------------------------
Patching file openjdk/hotspot/src/share/vm/runtime/arguments.cpp using Plan A...
Hunk #1 succeeded at 1140 (offset -21 lines).
Hunk #2 succeeded at 1159 (offset -21 lines).
Hunk #3 succeeded at 1201 (offset -21 lines).
Hunk #4 succeeded at 1213 (offset -21 lines).
done
Checking patches/clean-crypto.patch
Applying patches/clean-crypto.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/javax/crypto/Makefile openjdk/jdk/make/javax/crypto/Makefile
|--- openjdk.orig/jdk/make/javax/crypto/Makefile	2010-05-26 09:32:35.000000000 +0100
|+++ openjdk/jdk/make/javax/crypto/Makefile	2010-05-26 13:53:03.000000000 +0100
--------------------------
Patching file openjdk/jdk/make/javax/crypto/Makefile using Plan A...
Hunk #1 succeeded at 155.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/classes/javax/crypto/Cipher.java openjdk/jdk/src/share/classes/javax/crypto/Cipher.java
|--- openjdk.orig/jdk/src/share/classes/javax/crypto/Cipher.java	2010-05-26 09:32:39.000000000 +0100
|+++ openjdk/jdk/src/share/classes/javax/crypto/Cipher.java	2010-05-26 13:53:03.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/share/classes/javax/crypto/Cipher.java using Plan A...
Hunk #1 succeeded at 144.
Hunk #2 succeeded at 184.
Hunk #3 succeeded at 199.
Hunk #4 succeeded at 428.
Hunk #5 succeeded at 553.
Hunk #6 succeeded at 560.
Hunk #7 succeeded at 572.
Hunk #8 succeeded at 590.
Hunk #9 succeeded at 631.
Hunk #10 succeeded at 648.
Hunk #11 succeeded at 679.
Hunk #12 succeeded at 721.
Hunk #13 succeeded at 734.
Hunk #14 succeeded at 879.
Hunk #15 succeeded at 983.
Hunk #16 succeeded at 1108.
Hunk #17 succeeded at 1228.
Hunk #18 succeeded at 1391.
Hunk #19 succeeded at 2196.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/classes/javax/crypto/JarVerifier.java openjdk/jdk/src/share/classes/javax/crypto/JarVerifier.java
|--- openjdk.orig/jdk/src/share/classes/javax/crypto/JarVerifier.java	2010-05-26 09:32:39.000000000 +0100
|+++ openjdk/jdk/src/share/classes/javax/crypto/JarVerifier.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/share/classes/javax/crypto/JarVerifier.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/classes/javax/crypto/JceSecurity.java openjdk/jdk/src/share/classes/javax/crypto/JceSecurity.java
|--- openjdk.orig/jdk/src/share/classes/javax/crypto/JceSecurity.java	2010-05-26 09:32:39.000000000 +0100
|+++ openjdk/jdk/src/share/classes/javax/crypto/JceSecurity.java	2010-05-26 13:53:03.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/share/classes/javax/crypto/JceSecurity.java using Plan A...
Hunk #1 succeeded at 25.
Hunk #2 succeeded at 44.
Hunk #3 succeeded at 72.
Hunk #4 succeeded at 83.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/classes/javax/crypto/JceSecurityManager.java openjdk/jdk/src/share/classes/javax/crypto/JceSecurityManager.java
|--- openjdk.orig/jdk/src/share/classes/javax/crypto/JceSecurityManager.java	2010-05-26 09:32:39.000000000 +0100
|+++ openjdk/jdk/src/share/classes/javax/crypto/JceSecurityManager.java	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/share/classes/javax/crypto/JceSecurityManager.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/test/com/sun/crypto/provider/Cipher/UTIL/TestUtil.java openjdk/jdk/test/com/sun/crypto/provider/Cipher/UTIL/TestUtil.java
|--- openjdk.orig/jdk/test/com/sun/crypto/provider/Cipher/UTIL/TestUtil.java	2010-05-26 09:32:56.000000000 +0100
|+++ openjdk/jdk/test/com/sun/crypto/provider/Cipher/UTIL/TestUtil.java	2010-05-26 13:53:03.000000000 +0100
--------------------------
Patching file openjdk/jdk/test/com/sun/crypto/provider/Cipher/UTIL/TestUtil.java using Plan A...
Hunk #1 succeeded at 44.
done
Checking patches/arch.patch
Applying patches/arch.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/jdk/make/javax/sound/SoundDefs.gmk.orig	2008-10-15 17:04:19.000000000 +0200
|+++ openjdk/jdk/make/javax/sound/SoundDefs.gmk	2008-10-15 17:09:56.000000000 +0200
--------------------------
Patching file openjdk/jdk/make/javax/sound/SoundDefs.gmk using Plan A...
Hunk #1 succeeded at 58 with fuzz 1.
Hunk #2 succeeded at 113.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/jdk/make/common/Defs-linux.gmk.orig	2008-10-15 17:04:21.000000000 +0200
|+++ openjdk/jdk/make/common/Defs-linux.gmk	2008-10-15 17:08:37.000000000 +0200
--------------------------
Patching file openjdk/jdk/make/common/Defs-linux.gmk using Plan A...
Hunk #1 succeeded at 102.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/jdk/make/common/shared/Compiler-gcc.gmk.orig	2008-10-15 17:04:19.000000000 +0200
|+++ openjdk/jdk/make/common/shared/Compiler-gcc.gmk	2008-10-15 17:11:28.000000000 +0200
--------------------------
Patching file openjdk/jdk/make/common/shared/Compiler-gcc.gmk using Plan A...
Hunk #1 succeeded at 70.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/jdk/make/common/shared/Platform.gmk.orig	2008-10-15 17:04:19.000000000 +0200
|+++ openjdk/jdk/make/common/shared/Platform.gmk	2008-10-15 17:13:49.000000000 +0200
--------------------------
Patching file openjdk/jdk/make/common/shared/Platform.gmk using Plan A...
Hunk #1 succeeded at 222 (offset -15 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/jdk/src/share/native/com/sun/media/sound/SoundDefs.h.orig	2008-10-15 17:04:19.000000000 +0200
|+++ openjdk/jdk/src/share/native/com/sun/media/sound/SoundDefs.h	2008-10-15 17:13:01.000000000 +0200
--------------------------
Patching file openjdk/jdk/src/share/native/com/sun/media/sound/SoundDefs.h using Plan A...
Hunk #1 succeeded at 33.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/corba/make/common/Defs-linux.gmk.orig	2008-10-15 17:04:20.000000000 +0200
|+++ openjdk/corba/make/common/Defs-linux.gmk	2008-10-15 17:08:37.000000000 +0200
--------------------------
Patching file openjdk/corba/make/common/Defs-linux.gmk using Plan A...
Hunk #1 succeeded at 92.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/corba/make/common/shared/Platform.gmk.orig	2008-10-15 17:04:19.000000000 +0200
|+++ openjdk/corba/make/common/shared/Platform.gmk	2008-10-15 17:12:19.000000000 +0200
--------------------------
Patching file openjdk/corba/make/common/shared/Platform.gmk using Plan A...
Hunk #1 succeeded at 220 (offset -7 lines).
done
Checking patches/lc_ctype.patch
Applying patches/lc_ctype.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- oldopenjdk6/jdk/src/solaris/native/java/lang/java_props_md.c	2008-08-28 04:15:51.000000000 -0400
|+++ openjdk/jdk/src/solaris/native/java/lang/java_props_md.c	2008-09-15 10:37:26.000000000 -0400
--------------------------
Patching file openjdk/jdk/src/solaris/native/java/lang/java_props_md.c using Plan A...
Hunk #1 succeeded at 211.
Hunk #2 succeeded at 325.
done
Checking patches/xjc.patch
Applying patches/xjc.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jaxws/build.properties openjdk/jaxws/build.properties
|--- openjdk.orig/jaxws/build.properties	2009-12-04 16:41:02.000000000 +0000
|+++ openjdk/jaxws/build.properties	2009-12-04 16:41:47.000000000 +0000
--------------------------
Patching file openjdk/jaxws/build.properties using Plan A...
Hunk #1 succeeded at 77 (offset 4 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jaxws/patches/jaxws_src/xjc.patch openjdk/jaxws/patches/jaxws_src/xjc.patch
|--- openjdk.orig/jaxws/patches/jaxws_src/xjc.patch	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jaxws/patches/jaxws_src/xjc.patch	2009-12-04 16:40:10.000000000 +0000
--------------------------
(Creating file openjdk/jaxws/patches/jaxws_src/xjc.patch...)
Patching file openjdk/jaxws/patches/jaxws_src/xjc.patch using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/linker-libs-order.patch
Applying patches/linker-libs-order.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -durN openjdk-orig/jdk/make/common/shared/Sanity.gmk openjdk/jdk/make/common/shared/Sanity.gmk
|--- openjdk-orig/jdk/make/common/shared/Sanity.gmk	2008-10-27 00:25:33.000000000 +0000
|+++ openjdk/jdk/make/common/shared/Sanity.gmk	2008-10-28 21:42:16.000000000 +0000
--------------------------
Patching file openjdk/jdk/make/common/shared/Sanity.gmk using Plan A...
Hunk #1 succeeded at 1344 (offset -53 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -durN openjdk-orig/jdk/make/javax/sound/jsoundalsa/Makefile openjdk/jdk/make/javax/sound/jsoundalsa/Makefile
|--- openjdk-orig/jdk/make/javax/sound/jsoundalsa/Makefile	2008-08-28 09:10:50.000000000 +0100
|+++ openjdk/jdk/make/javax/sound/jsoundalsa/Makefile	2008-10-28 21:55:27.000000000 +0000
--------------------------
Patching file openjdk/jdk/make/javax/sound/jsoundalsa/Makefile using Plan A...
Hunk #1 succeeded at 65.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -durN openjdk-orig/jdk/make/com/sun/java/pack/Makefile openjdk/jdk/make/com/sun/java/pack/Makefile
|--- openjdk-orig/jdk/make/com/sun/java/pack/Makefile	2008-10-27 00:25:30.000000000 +0000
|+++ openjdk/jdk/make/com/sun/java/pack/Makefile	2008-10-28 23:27:55.000000000 +0000
--------------------------
Patching file openjdk/jdk/make/com/sun/java/pack/Makefile using Plan A...
Hunk #1 succeeded at 75.
Hunk #2 succeeded at 100.
Hunk #3 succeeded at 141.
done
Checking patches/testenv.patch
Applying patches/testenv.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk.orig/jdk/test/java/nio/channels/SocketChannel/LocalAddress.java	2008-11-05 10:20:19.000000000 +0100
|+++ openjdk/jdk/test/java/nio/channels/SocketChannel/LocalAddress.java	2008-11-15 22:07:26.000000000 +0100
--------------------------
Patching file openjdk/jdk/test/java/nio/channels/SocketChannel/LocalAddress.java using Plan A...
Hunk #1 succeeded at 40.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk.orig/jdk/test/java/nio/channels/SocketChannel/Shutdown.java	2008-11-05 10:20:19.000000000 +0100
|+++ openjdk/jdk/test/java/nio/channels/SocketChannel/Shutdown.java	2008-11-15 22:07:51.000000000 +0100
--------------------------
Patching file openjdk/jdk/test/java/nio/channels/SocketChannel/Shutdown.java using Plan A...
Hunk #1 succeeded at 35.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- ../openjdk6/jdk/test/sun/net/InetAddress/nameservice/dns/cname.sh	2008-11-05 10:21:00.000000000 +0100
|+++ openjdk/jdk/test/sun/net/InetAddress/nameservice/dns/cname.sh	2008-11-15 22:58:14.000000000 +0100
--------------------------
Patching file openjdk/jdk/test/sun/net/InetAddress/nameservice/dns/cname.sh using Plan A...
Hunk #1 succeeded at 26.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk.orig/jdk/test/TestEnv.java	2008-11-05 10:16:16.000000000 +0100
|+++ openjdk/jdk/test/TestEnv.java	2008-11-15 22:42:11.000000000 +0100
--------------------------
Patching file openjdk/jdk/test/TestEnv.java using Plan A...
Hunk #1 succeeded at 65.
done
Checking patches/samejvm-safe.patch
Applying patches/samejvm-safe.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk.orig/jdk/test/TEST.ROOT	2008-11-06 09:44:52.000000000 +0100
|+++ openjdk/jdk/test/TEST.ROOT	2008-11-23 16:15:53.000000000 +0100
--------------------------
Patching file openjdk/jdk/test/TEST.ROOT using Plan A...
Hunk #1 succeeded at 4.
done
Checking patches/pr261.patch
Applying patches/pr261.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r fa4572c7c75f openjdk-ecj/jdk/make/java/nio/Makefile
|--- openjdk/jdk/make/java/nio/Makefile	Thu Nov 27 08:42:23 2008 +0000
|+++ openjdk/jdk/make/java/nio/Makefile	Thu Nov 27 10:12:08 2008 +0000
--------------------------
Patching file openjdk/jdk/make/java/nio/Makefile using Plan A...
Hunk #1 succeeded at 85.
Hunk #2 succeeded at 102.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 3ee709488c6c openjdk-ecj/jdk/make/java/nio/FILES_java.gmk
|--- openjdk/jdk/make/java/nio/FILES_java.gmk	Thu Nov 27 10:16:56 2008 +0000
|+++ openjdk/jdk/make/java/nio/FILES_java.gmk	Thu Nov 27 11:08:57 2008 +0000
--------------------------
Patching file openjdk/jdk/make/java/nio/FILES_java.gmk using Plan A...
Hunk #1 succeeded at 31.
Hunk #2 succeeded at 39.
done
Checking patches/sparc-buildfixes.patch
Applying patches/sparc-buildfixes.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/make/linux/makefiles/defs.make openjdk/hotspot/make/linux/makefiles/defs.make
|--- openjdk.orig/hotspot/make/linux/makefiles/defs.make	2011-01-25 22:57:24.000000000 +0000
|+++ openjdk/hotspot/make/linux/makefiles/defs.make	2011-01-28 01:21:25.609237228 +0000
--------------------------
Patching file openjdk/hotspot/make/linux/makefiles/defs.make using Plan A...
Hunk #1 succeeded at 58.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/make/linux/makefiles/gcc.make openjdk/hotspot/make/linux/makefiles/gcc.make
|--- openjdk.orig/hotspot/make/linux/makefiles/gcc.make	2011-01-28 01:14:57.000000000 +0000
|+++ openjdk/hotspot/make/linux/makefiles/gcc.make	2011-01-28 01:21:25.609237228 +0000
--------------------------
Patching file openjdk/hotspot/make/linux/makefiles/gcc.make using Plan A...
Hunk #1 succeeded at 64.
done
Checking patches/sparc64-linux.patch
Applying patches/sparc64-linux.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp openjdk/hotspot/src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp
|--- openjdk.orig/hotspot/src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp	2008-06-22 20:44:41.000000000 +0100
|+++ openjdk/hotspot/src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp	2008-06-22 22:35:27.000000000 +0100
--------------------------
Patching file openjdk/hotspot/src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp using Plan A...
Hunk #1 succeeded at 1145 (offset 33 lines).
done
Checking patches/sparc-ptracefix.patch
Applying patches/sparc-ptracefix.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -up openjdk/hotspot/agent/src/os/linux/libproc.h.BAD openjdk/hotspot/agent/src/os/linux/libproc.h
|--- openjdk/hotspot/agent/src/os/linux/libproc.h.BAD	2008-05-29 19:03:34.000000000 -0400
|+++ openjdk/hotspot/agent/src/os/linux/libproc.h	2008-05-29 19:01:45.000000000 -0400
--------------------------
Patching file openjdk/hotspot/agent/src/os/linux/libproc.h using Plan A...
Hunk #1 succeeded at 31 (offset -3 lines).
done
Checking patches/sparc-trapsfix.patch
Applying patches/sparc-trapsfix.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/hotspot/src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp.orig	2010-01-16 23:19:45.703450297 +0000
|+++ openjdk/hotspot/src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp	2010-01-16 23:21:23.942337146 +0000
--------------------------
Patching file openjdk/hotspot/src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp using Plan A...
Hunk #1 succeeded at 28 with fuzz 2 (offset 3 lines).
done
Checking patches/jtreg-6592792.patch
Applying patches/jtreg-6592792.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/jdk/test/com/sun/org/apache/xml/internal/ws/server.bak/Test6592792.sh	2009-03-13 15:08:37.000000000 -0400
|+++ openjdk/jdk/test/com/sun/org/apache/xml/internal/ws/server/Test6592792.sh	2009-03-13 15:57:46.000000000 -0400
--------------------------
Patching file openjdk/jdk/test/com/sun/org/apache/xml/internal/ws/server/Test6592792.sh using Plan A...
Hunk #1 succeeded at 52.
done
Checking patches/s390-noinline.patch
Applying patches/s390-noinline.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/corba/make/common/shared/Defs-java.gmk.orig	2009-03-13 06:30:44.000000000 +0100
|+++ openjdk/corba/make/common/shared/Defs-java.gmk	2009-03-13 06:30:04.000000000 +0100
--------------------------
Patching file openjdk/corba/make/common/shared/Defs-java.gmk using Plan A...
Hunk #1 succeeded at 32.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/jdk/make/common/shared/Defs-java.gmk.orig	2009-03-13 00:07:32.000000000 +0100
|+++ openjdk/jdk/make/common/shared/Defs-java.gmk	2009-03-13 07:40:42.000000000 +0100
--------------------------
Patching file openjdk/jdk/make/common/shared/Defs-java.gmk using Plan A...
Hunk #1 succeeded at 36.
done
Checking patches/jtreg-dnd.patch
Applying patches/jtreg-dnd.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/jdk/test/java/awt/regtesthelpers/process/ProcessCommunicator.java.orig	2009-03-30 11:41:32.000000000 -0400
|+++ openjdk/jdk/test/java/awt/regtesthelpers/process/ProcessCommunicator.java	2009-03-30 11:44:21.000000000 -0400
--------------------------
Patching file openjdk/jdk/test/java/awt/regtesthelpers/process/ProcessCommunicator.java using Plan A...
Hunk #1 succeeded at 146.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/jdk/test/java/awt/dnd/FileListBetweenJVMsTest/FileListBetweenJVMsTest.java.orig	2009-03-30 11:45:16.000000000 -0400
|+++ openjdk/jdk/test/java/awt/dnd/FileListBetweenJVMsTest/FileListBetweenJVMsTest.java	2009-03-30 11:46:51.000000000 -0400
--------------------------
Patching file openjdk/jdk/test/java/awt/dnd/FileListBetweenJVMsTest/FileListBetweenJVMsTest.java using Plan A...
Hunk #1 succeeded at 69.
done
Checking patches/jtreg-jrunscript.patch
Applying patches/jtreg-jrunscript.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/test/sun/tools/jrunscript/CheckEngine.java openjdk/jdk/test/sun/tools/jrunscript/CheckEngine.java
|--- openjdk.orig/jdk/test/sun/tools/jrunscript/CheckEngine.java	2010-05-26 09:33:18.000000000 +0100
|+++ openjdk/jdk/test/sun/tools/jrunscript/CheckEngine.java	2010-07-28 12:43:18.282489286 +0100
--------------------------
Patching file openjdk/jdk/test/sun/tools/jrunscript/CheckEngine.java using Plan A...
Hunk #1 succeeded at 39.
Hunk #2 succeeded at 49.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/test/sun/tools/jrunscript/jrunscriptTest.sh openjdk/jdk/test/sun/tools/jrunscript/jrunscriptTest.sh
|--- openjdk.orig/jdk/test/sun/tools/jrunscript/jrunscriptTest.sh	2010-07-28 11:14:05.000000000 +0100
|+++ openjdk/jdk/test/sun/tools/jrunscript/jrunscriptTest.sh	1970-01-01 01:00:00.000000000 +0100
--------------------------
Patching file openjdk/jdk/test/sun/tools/jrunscript/jrunscriptTest.sh using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/test/sun/tools/jrunscript/Testjrunscript.java openjdk/jdk/test/sun/tools/jrunscript/Testjrunscript.java
|--- openjdk.orig/jdk/test/sun/tools/jrunscript/Testjrunscript.java	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/test/sun/tools/jrunscript/Testjrunscript.java	2010-07-28 12:43:18.282489286 +0100
--------------------------
(Creating file openjdk/jdk/test/sun/tools/jrunscript/Testjrunscript.java...)
Patching file openjdk/jdk/test/sun/tools/jrunscript/Testjrunscript.java using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/network-unreachable.patch
Applying patches/network-unreachable.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/jdk/src/solaris/native/java/net/PlainSocketImpl.c.orig	2008-11-25 04:06:19.000000000 -0500
|+++ openjdk/jdk/src/solaris/native/java/net/PlainSocketImpl.c	2009-03-20 16:58:35.000000000 -0400
--------------------------
Patching file openjdk/jdk/src/solaris/native/java/net/PlainSocketImpl.c using Plan A...
Hunk #1 succeeded at 410.
Hunk #2 succeeded at 548.
done
Checking patches/dnd-filelists.patch
Applying patches/dnd-filelists.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/jdk/src/share/classes/sun/awt/datatransfer/DataTransferer.java.orig	2009-04-06 16:17:44.000000000 -0400
|+++ openjdk/jdk/src/share/classes/sun/awt/datatransfer/DataTransferer.java	2009-04-06 16:33:42.000000000 -0400
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/awt/datatransfer/DataTransferer.java using Plan A...
Hunk #1 succeeded at 1327.
done
Checking patches/disable-cc-incompatible-sanity-checks.patch
Applying patches/disable-cc-incompatible-sanity-checks.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/common/Sanity.gmk openjdk/jdk/make/common/Sanity.gmk
|--- openjdk.orig/jdk/make/common/Sanity.gmk	2009-10-01 18:31:50.000000000 +0100
|+++ openjdk/jdk/make/common/Sanity.gmk	2009-10-02 17:51:35.000000000 +0100
--------------------------
Patching file openjdk/jdk/make/common/Sanity.gmk using Plan A...
Hunk #1 succeeded at 91 (offset -1 lines).
Hunk #2 succeeded at 111 (offset -1 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/common/shared/Sanity.gmk openjdk/jdk/make/common/shared/Sanity.gmk
|--- openjdk.orig/jdk/make/common/shared/Sanity.gmk	2009-10-02 17:36:09.000000000 +0100
|+++ openjdk/jdk/make/common/shared/Sanity.gmk	2009-10-02 17:52:37.000000000 +0100
--------------------------
Patching file openjdk/jdk/make/common/shared/Sanity.gmk using Plan A...
Hunk #1 succeeded at 71 (offset -4 lines).
Hunk #2 succeeded at 123 (offset -2 lines).
Hunk #3 succeeded at 158 (offset -5 lines).
Hunk #4 succeeded at 178 (offset -2 lines).
done
Checking patches/explicit-target-arch.patch
Applying patches/explicit-target-arch.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: openjdk/hotspot/make/linux/makefiles/defs.make
|===================================================================
|--- openjdk.orig/hotspot/make/linux/makefiles/defs.make	2009-05-18 14:09:57.812930043 +0200
|+++ openjdk/hotspot/make/linux/makefiles/defs.make	2009-05-18 14:30:46.318871170 +0200
--------------------------
Patching file openjdk/hotspot/make/linux/makefiles/defs.make using Plan A...
Hunk #1 succeeded at 29.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: openjdk/jdk/make/common/shared/Platform.gmk
|===================================================================
|--- openjdk.orig/jdk/make/common/shared/Platform.gmk	2009-05-18 14:09:57.950854863 +0200
|+++ openjdk/jdk/make/common/shared/Platform.gmk	2009-05-18 14:18:59.387528133 +0200
--------------------------
Patching file openjdk/jdk/make/common/shared/Platform.gmk using Plan A...
Hunk #1 succeeded at 180 (offset -10 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: openjdk/corba/make/common/shared/Platform.gmk
|===================================================================
|--- openjdk.orig/corba/make/common/shared/Platform.gmk	2009-05-18 14:09:58.044921758 +0200
|+++ openjdk/corba/make/common/shared/Platform.gmk	2009-05-18 14:17:30.760805124 +0200
--------------------------
Patching file openjdk/corba/make/common/shared/Platform.gmk using Plan A...
Hunk #1 succeeded at 177 (offset -2 lines).
done
Checking patches/openjdk/7019808-stack_noexec.patch
Applying patches/openjdk/7019808-stack_noexec.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User dsamersoff
|# Date 1304097180 -14400
|# Node ID dddc5753c53a063c94c9949c623babe4f946c7e6
|# Parent  0cddebc420d8b0fff85f4e0071d531e966372b80
|7019808: build fails on Fedora 14: SELinux run-time check: execution of stack in libjvm.so
|Summary: executable flag is set in the elf header of libjvm.so during build, instruct ld to don't do it.
|Reviewed-by: acorn, phh
|
|diff -r 0cddebc420d8 -r dddc5753c53a make/linux/makefiles/vm.make
|--- openjdk/hotspot/make/linux/makefiles/vm.make	Thu Apr 28 08:24:46 2011 -0700
|+++ openjdk/hotspot/make/linux/makefiles/vm.make	Fri Apr 29 21:13:00 2011 +0400
--------------------------
Patching file openjdk/hotspot/make/linux/makefiles/vm.make using Plan A...
Hunk #1 succeeded at 109 (offset 7 lines).
done
Checking patches/parisc.patch
Applying patches/parisc.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/jdk/make/common/shared/Compiler-gcc.gmk.orig	2009-12-19 12:45:34.000000000 +0000
|+++ openjdk/jdk/make/common/shared/Compiler-gcc.gmk	2009-12-19 12:45:09.000000000 +0000
--------------------------
Patching file openjdk/jdk/make/common/shared/Compiler-gcc.gmk using Plan A...
Hunk #1 succeeded at 106.
done
Checking patches/sh4-support.patch
Applying patches/sh4-support.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/corba/make/common/Defs-linux.gmk openjdk/corba/make/common/Defs-linux.gmk
|--- openjdk.orig/corba/make/common/Defs-linux.gmk	2010-06-06 19:02:13.000000000 +0100
|+++ openjdk/corba/make/common/Defs-linux.gmk	2010-06-06 19:02:52.000000000 +0100
--------------------------
Patching file openjdk/corba/make/common/Defs-linux.gmk using Plan A...
Hunk #1 succeeded at 109.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/corba/make/common/shared/Platform.gmk openjdk/corba/make/common/shared/Platform.gmk
|--- openjdk.orig/corba/make/common/shared/Platform.gmk	2010-06-06 19:02:15.000000000 +0100
|+++ openjdk/corba/make/common/shared/Platform.gmk	2010-06-06 19:02:52.000000000 +0100
--------------------------
Patching file openjdk/corba/make/common/shared/Platform.gmk using Plan A...
Hunk #1 succeeded at 203.
Hunk #2 succeeded at 264.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/src/os/linux/vm/os_linux.cpp openjdk/hotspot/src/os/linux/vm/os_linux.cpp
|--- openjdk.orig/hotspot/src/os/linux/vm/os_linux.cpp	2010-06-06 19:02:12.000000000 +0100
|+++ openjdk/hotspot/src/os/linux/vm/os_linux.cpp	2010-06-06 19:02:52.000000000 +0100
--------------------------
Patching file openjdk/hotspot/src/os/linux/vm/os_linux.cpp using Plan A...
Hunk #1 succeeded at 1855 (offset 103 lines).
Hunk #2 succeeded at 1887 (offset 103 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/common/Defs-linux.gmk openjdk/jdk/make/common/Defs-linux.gmk
|--- openjdk.orig/jdk/make/common/Defs-linux.gmk	2010-06-06 19:02:13.000000000 +0100
|+++ openjdk/jdk/make/common/Defs-linux.gmk	2010-06-06 19:15:05.000000000 +0100
--------------------------
Patching file openjdk/jdk/make/common/Defs-linux.gmk using Plan A...
Hunk #1 succeeded at 119.
Hunk #2 succeeded at 205.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/common/shared/Compiler-gcc.gmk openjdk/jdk/make/common/shared/Compiler-gcc.gmk
|--- openjdk.orig/jdk/make/common/shared/Compiler-gcc.gmk	2010-06-06 19:02:15.000000000 +0100
|+++ openjdk/jdk/make/common/shared/Compiler-gcc.gmk	2010-06-06 19:02:52.000000000 +0100
--------------------------
Patching file openjdk/jdk/make/common/shared/Compiler-gcc.gmk using Plan A...
Hunk #1 succeeded at 126.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/common/shared/Platform.gmk openjdk/jdk/make/common/shared/Platform.gmk
|--- openjdk.orig/jdk/make/common/shared/Platform.gmk	2010-06-06 19:02:15.000000000 +0100
|+++ openjdk/jdk/make/common/shared/Platform.gmk	2010-06-06 19:02:52.000000000 +0100
--------------------------
Patching file openjdk/jdk/make/common/shared/Platform.gmk using Plan A...
Hunk #1 succeeded at 204 (offset -8 lines).
Hunk #2 succeeded at 265 (offset -8 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/javax/sound/SoundDefs.gmk openjdk/jdk/make/javax/sound/SoundDefs.gmk
|--- openjdk.orig/jdk/make/javax/sound/SoundDefs.gmk	2010-06-06 19:02:13.000000000 +0100
|+++ openjdk/jdk/make/javax/sound/SoundDefs.gmk	2010-06-06 19:02:52.000000000 +0100
--------------------------
Patching file openjdk/jdk/make/javax/sound/SoundDefs.gmk using Plan A...
Hunk #1 succeeded at 113.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/jdk_generic_profile.sh openjdk/jdk/make/jdk_generic_profile.sh
|--- openjdk.orig/jdk/make/jdk_generic_profile.sh	2010-05-26 09:32:36.000000000 +0100
|+++ openjdk/jdk/make/jdk_generic_profile.sh	2010-06-06 19:02:52.000000000 +0100
--------------------------
Patching file openjdk/jdk/make/jdk_generic_profile.sh using Plan A...
Hunk #1 succeeded at 326 (offset -24 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/share/native/com/sun/media/sound/SoundDefs.h openjdk/jdk/src/share/native/com/sun/media/sound/SoundDefs.h
|--- openjdk.orig/jdk/src/share/native/com/sun/media/sound/SoundDefs.h	2010-06-06 19:02:13.000000000 +0100
|+++ openjdk/jdk/src/share/native/com/sun/media/sound/SoundDefs.h	2010-06-06 19:02:52.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/share/native/com/sun/media/sound/SoundDefs.h using Plan A...
Hunk #1 succeeded at 47.
done
Checking patches/policy-evaluation.patch
Applying patches/policy-evaluation.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# This patch aligns policy evaluation to be the same as the proprietary JDK.
|# http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-July/009658.html
|# https://bugs.openjdk.java.net/show_bug.cgi?id=100142
|
|diff -up ./openjdk/jdk/src/share/classes/sun/security/provider/PolicyFile.java.sav ./jdk/src/share/classes/sun/security/provider/PolicyFile.java
|--- ./openjdk.orig/jdk/src/share/classes/sun/security/provider/PolicyFile.java.sav	2010-04-20 14:49:13.000000000 -0400
|+++ ./openjdk/jdk/src/share/classes/sun/security/provider/PolicyFile.java	2010-04-20 14:50:26.000000000 -0400
--------------------------
Patching file ./openjdk/jdk/src/share/classes/sun/security/provider/PolicyFile.java using Plan A...
Hunk #1 succeeded at 1799.
done
Checking patches/update-bootclasspath.patch
Applying patches/update-bootclasspath.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/src/share/vm/runtime/os.cpp openjdk/hotspot/src/share/vm/runtime/os.cpp
|--- openjdk.orig/hotspot/src/share/vm/runtime/os.cpp	2010-09-01 01:23:45.000000000 +0100
|+++ openjdk/hotspot/src/share/vm/runtime/os.cpp	2010-09-19 17:34:30.859345954 +0100
--------------------------
Patching file openjdk/hotspot/src/share/vm/runtime/os.cpp using Plan A...
Hunk #1 succeeded at 1075 (offset 43 lines).
done
Checking patches/openjdk/6959123-libpng_14.patch
Applying patches/openjdk/6959123-libpng_14.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User andrew
|# Date 1276015967 -3600
|# Node ID 4d55419ce99e749da5037fa4d8247117f1a5cc2e
|# Parent  be6f14f83ea7cfbb4b9d167d853b1fda420bb2cf
|6959123: Remove use of obsolete png_check_sig function in splashscreen_png.c
|Summary: Avoid use of deprecated libpng macro (removed in some 1.4.x releases)
|Reviewed-by: prr
|
|diff --git a/src/share/native/sun/awt/splashscreen/splashscreen_png.c b/src/share/native/sun/awt/splashscreen/splashscreen_png.c
|--- openjdk/jdk/src/share/native/sun/awt/splashscreen/splashscreen_png.c
|+++ openjdk/jdk/src/share/native/sun/awt/splashscreen/splashscreen_png.c
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/splashscreen/splashscreen_png.c using Plan A...
Hunk #1 succeeded at 182.
done
Checking patches/applet_hole.patch
Applying patches/applet_hole.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r fbc7931ae89b src/share/classes/sun/applet/AppletPanel.java
|--- openjdk.orig/jdk/src/share/classes/sun/applet/AppletPanel.java	Fri Nov 12 12:08:44 2010 +0000
|+++ openjdk/jdk/src/share/classes/sun/applet/AppletPanel.java	Thu Dec 02 01:45:58 2010 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/applet/AppletPanel.java using Plan A...
Hunk #1 succeeded at 68.
Hunk #2 succeeded at 117.
Hunk #3 succeeded at 162.
Hunk #4 succeeded at 307.
Hunk #5 succeeded at 696.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r fbc7931ae89b src/share/classes/sun/applet/AppletViewerPanel.java
|--- openjdk.orig/jdk/src/share/classes/sun/applet/AppletViewerPanel.java	Fri Nov 12 12:08:44 2010 +0000
|+++ openjdk/jdk/src/share/classes/sun/applet/AppletViewerPanel.java	Thu Dec 02 01:45:58 2010 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/applet/AppletViewerPanel.java using Plan A...
Hunk #1 succeeded at 42.
Hunk #2 succeeded at 70.
Hunk #3 succeeded at 106.
Hunk #4 succeeded at 202.
done
Checking patches/jtreg-httpTest.patch
Applying patches/jtreg-httpTest.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- /dev/null		2010-03-18 17:24:04.000000000 +0100
|+++ openjdk/jdk/test/java/net/URL/TestHttps.java	2010-03-18 17:24:04.000000000 +0100
--------------------------
(Creating file openjdk/jdk/test/java/net/URL/TestHttps.java...)
Patching file openjdk/jdk/test/java/net/URL/TestHttps.java using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/arm.patch
Applying patches/arm.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/make/linux/makefiles/zeroshark.make openjdk/hotspot/make/linux/makefiles/zeroshark.make
|--- openjdk.orig/hotspot/make/linux/makefiles/zeroshark.make	2010-05-28 11:09:25.000000000 +0100
|+++ openjdk/hotspot/make/linux/makefiles/zeroshark.make	2010-06-17 17:28:03.000000000 +0100
--------------------------
Patching file openjdk/hotspot/make/linux/makefiles/zeroshark.make using Plan A...
Hunk #1 succeeded at 25.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/src/cpu/zero/vm/bytecodes_zero.cpp openjdk/hotspot/src/cpu/zero/vm/bytecodes_zero.cpp
|--- openjdk.orig/hotspot/src/cpu/zero/vm/bytecodes_zero.cpp	2010-05-28 11:10:30.000000000 +0100
|+++ openjdk/hotspot/src/cpu/zero/vm/bytecodes_zero.cpp	2010-06-17 17:29:30.000000000 +0100
--------------------------
Patching file openjdk/hotspot/src/cpu/zero/vm/bytecodes_zero.cpp using Plan A...
Hunk #1 succeeded at 1 with fuzz 2.
Hunk #2 succeeded at 28 with fuzz 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp openjdk/hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp
|--- openjdk.orig/hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp	2010-06-16 14:11:07.000000000 +0100
|+++ openjdk/hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp	2010-06-17 17:30:02.000000000 +0100
--------------------------
Patching file openjdk/hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp using Plan A...
Hunk #1 succeeded at 749 (offset 25 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.cpp openjdk/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.cpp
|--- openjdk.orig/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.cpp	2010-05-28 11:11:05.000000000 +0100
|+++ openjdk/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.cpp	2010-06-17 17:27:35.000000000 +0100
--------------------------
Patching file openjdk/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.cpp using Plan A...
Hunk #1 succeeded at 116 (offset 34 lines).
Hunk #2 succeeded at 127 (offset 34 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/hotspot/src/cpu/zero/vm/bytecodes_zero.hpp openjdk/hotspot/src/cpu/zero/vm/bytecodes_zero.hpp
|--- openjdk.orig/hotspot/src/cpu/zero/vm/bytecodes_zero.hpp	2011-01-25 22:57:24.000000000 +0000
|+++ openjdk/hotspot/src/cpu/zero/vm/bytecodes_zero.hpp	2011-01-28 01:46:18.769782690 +0000
--------------------------
Patching file openjdk/hotspot/src/cpu/zero/vm/bytecodes_zero.hpp using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 27.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/hotspot/make/linux/makefiles/vm.make	2011-09-16 14:22:51.000000000 +0100
|+++ openjdk/hotspot/make/linux/makefiles/vm.make	2011-09-16 16:04:50.000000000 +0100
--------------------------
Patching file openjdk/hotspot/make/linux/makefiles/vm.make using Plan A...
Hunk #1 succeeded at 181 (offset -2 lines).
done
Checking patches/debug-dir.patch
Applying patches/debug-dir.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/Makefile.orig	2010-06-28 20:11:00.000000000 +0100
|+++ openjdk/Makefile	2010-06-28 20:11:54.000000000 +0100
--------------------------
Patching file openjdk/Makefile using Plan A...
Hunk #1 succeeded at 138.
Hunk #2 succeeded at 210.
Hunk #3 succeeded at 230.
done
Checking patches/override-redirect-metacity.patch
Applying patches/override-redirect-metacity.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/jdk/src/solaris/classes/sun/awt/X11/XWindowPeer.java.orig	2008-05-25 17:31:31.000000000 +0200
|+++ openjdk/jdk/src/solaris/classes/sun/awt/X11/XWindowPeer.java	2008-05-25 17:33:32.000000000 +0200
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/X11/XWindowPeer.java using Plan A...
Hunk #1 succeeded at 1171 (offset 47 lines).
done
Checking patches/openjdk/6967533-pre_epoch.patch
Applying patches/openjdk/6967533-pre_epoch.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f13e94562d84 -r da8526047e5f src/share/classes/java/lang/System.java
|--- openjdk.old/jdk/src/share/classes/java/lang/System.java	Fri Jul 09 09:54:10 2010 -0700
|+++ openjdk/jdk/src/share/classes/java/lang/System.java	Fri Jul 09 18:55:25 2010 -0700
--------------------------
Patching file openjdk/jdk/src/share/classes/java/lang/System.java using Plan A...
Hunk #1 succeeded at 70 (offset 1 line).
Hunk #2 succeeded at 97 (offset 1 line).
Hunk #3 succeeded at 111 (offset 1 line).
Hunk #4 succeeded at 1061 (offset -32 lines).
done
Checking patches/fonts-rhel.patch
Applying patches/fonts-rhel.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r ea703df72762 make/sun/awt/Makefile
|--- openjdk.orig/jdk/make/sun/awt/Makefile	Mon Jul 26 13:05:38 2010 -0700
|+++ openjdk/jdk/make/sun/awt/Makefile	Mon Aug 02 16:56:20 2010 +0100
--------------------------
Patching file openjdk/jdk/make/sun/awt/Makefile using Plan A...
Hunk #1 succeeded at 387.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- /dev/null	2010-12-20 09:26:08.850062021 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.RedHat.6.properties	2010-12-22 11:21:32.606781127 +0100
--------------------------
(Creating file openjdk/jdk/src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.RedHat.6.properties...)
Patching file openjdk/jdk/src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.RedHat.6.properties using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/fonts-gentoo.patch
Applying patches/fonts-gentoo.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/sun/awt/Makefile openjdk/jdk/make/sun/awt/Makefile
|--- openjdk.orig/jdk/make/sun/awt/Makefile	2010-08-02 20:41:47.000000000 +0100
|+++ openjdk/jdk/make/sun/awt/Makefile	2010-08-02 20:47:24.593166977 +0100
--------------------------
Patching file openjdk/jdk/make/sun/awt/Makefile using Plan A...
Hunk #1 succeeded at 388.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Gentoo.properties openjdk/jdk/src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Gentoo.properties
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Gentoo.properties	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Gentoo.properties	2010-08-02 20:46:28.582307221 +0100
--------------------------
(Creating file openjdk/jdk/src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Gentoo.properties...)
Patching file openjdk/jdk/src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Gentoo.properties using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MFontConfiguration.java openjdk/jdk/src/solaris/classes/sun/awt/motif/MFontConfiguration.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/awt/motif/MFontConfiguration.java	2010-06-21 22:15:43.000000000 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/motif/MFontConfiguration.java	2010-08-02 20:46:28.582307221 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/motif/MFontConfiguration.java using Plan A...
Hunk #1 succeeded at 176.
done
Checking patches/ipv4-mapped-ipv6-addresses.patch
Applying patches/ipv4-mapped-ipv6-addresses.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN openjdk.orig/jdk/src/solaris/native/java/net/linux_close.c openjdk/jdk/src/solaris/native/java/net/linux_close.c
|--- openjdk.orig/jdk/src/solaris/native/java/net/linux_close.c	2010-02-17 04:14:47.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/java/net/linux_close.c	2010-03-27 20:24:26.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/java/net/linux_close.c using Plan A...
Hunk #1 succeeded at 37.
Hunk #2 succeeded at 303.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN openjdk.orig/jdk/src/solaris/native/java/net/net_util_md.c openjdk/jdk/src/solaris/native/java/net/net_util_md.c
|--- openjdk.orig/jdk/src/solaris/native/java/net/net_util_md.c	2010-02-17 04:14:47.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/java/net/net_util_md.c	2010-03-27 19:44:32.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/java/net/net_util_md.c using Plan A...
Hunk #1 succeeded at 1215.
Hunk #2 succeeded at 1284.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN openjdk.orig/jdk/src/solaris/native/java/net/net_util_md.h openjdk/jdk/src/solaris/native/java/net/net_util_md.h
|--- openjdk.orig/jdk/src/solaris/native/java/net/net_util_md.h	2010-02-17 04:14:47.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/java/net/net_util_md.h	2010-03-27 20:24:26.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/java/net/net_util_md.h using Plan A...
Hunk #1 succeeded at 36.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ruN openjdk.orig/jdk/src/solaris/native/java/net/PlainSocketImpl.c openjdk/jdk/src/solaris/native/java/net/PlainSocketImpl.c
|--- openjdk.orig/jdk/src/solaris/native/java/net/PlainSocketImpl.c	2010-03-27 20:23:58.000000000 +0100
|+++ openjdk/jdk/src/solaris/native/java/net/PlainSocketImpl.c	2010-03-27 20:24:26.000000000 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/java/net/PlainSocketImpl.c using Plan A...
Hunk #1 succeeded at 401.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- /dev/null	2010-08-03 19:26:41.444667773 +0100
|+++ openjdk/jdk/test/java/net/Socket/Bindv6Only.java	2010-08-05 15:41:55.000000000 +0100
--------------------------
(Creating file openjdk/jdk/test/java/net/Socket/Bindv6Only.java...)
Patching file openjdk/jdk/test/java/net/Socket/Bindv6Only.java using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/jtreg-OpenGLContextInit.patch
Applying patches/jtreg-OpenGLContextInit.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- /dev/null	2010-06-29 11:10:08.737208357 +0200
|+++ openjdk/jdk/test/sun/java2d/OpenGL/OpenGLContextInit.java	2010-09-01 16:27:44.000000000 +0200
--------------------------
(Creating file openjdk/jdk/test/sun/java2d/OpenGL/OpenGLContextInit.java...)
Patching file openjdk/jdk/test/sun/java2d/OpenGL/OpenGLContextInit.java using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/openjdk/6510892-httpserver_test.patch
Applying patches/openjdk/6510892-httpserver_test.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User michaelm
|# Date 1280510190 -3600
|# Node ID 4d72d0ec83f5e7870c3f38c0c238b8617273ee4d
|# Parent  48e6f4807e5f2c4fea2ac435ea92a1a7531019d8
|6510892: com/sun/net/httpserver/bugs/B6361557.java fails
|Reviewed-by: chegar
|
|diff -r 48e6f4807e5f -r 4d72d0ec83f5 test/com/sun/net/httpserver/bugs/B6361557.java
|--- openjdk.orig/jdk/test/com/sun/net/httpserver/bugs/B6361557.java	Thu Jul 29 22:02:45 2010 -0700
|+++ openjdk/jdk/test/com/sun/net/httpserver/bugs/B6361557.java	Fri Jul 30 18:16:30 2010 +0100
--------------------------
Patching file openjdk/jdk/test/com/sun/net/httpserver/bugs/B6361557.java using Plan A...
Hunk #1 succeeded at 24.
Hunk #2 succeeded at 64.
Hunk #3 succeeded at 77.
done
Checking patches/openjdk/6638712-wildcard_types.patch
Applying patches/openjdk/6638712-wildcard_types.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User mcimadamore
|# Date 1284137253 -3600
|# Node ID c5fe15e03287286fa8e668798409c4d7493ee834
|# Parent  27f03394a69d018c1c2badadee65ea39c7274606
|6638712: Inference with wildcard types causes selection of inapplicable method
|Summary: Added global sanity check in order to make sure that return type inference does not violate bounds constraints
|Reviewed-by: jjg
|
|diff -r 27f03394a69d -r c5fe15e03287 src/share/classes/com/sun/tools/javac/code/Type.java
|--- openjdk.orig/langtools/src/share/classes/com/sun/tools/javac/code/Type.java	Wed Jun 23 16:44:15 2010 -0700
|+++ openjdk/langtools/src/share/classes/com/sun/tools/javac/code/Type.java	Fri Sep 10 17:47:33 2010 +0100
--------------------------
Patching file openjdk/langtools/src/share/classes/com/sun/tools/javac/code/Type.java using Plan A...
Hunk #1 succeeded at 1061.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 27f03394a69d -r c5fe15e03287 src/share/classes/com/sun/tools/javac/code/Types.java
|--- openjdk.orig/langtools/src/share/classes/com/sun/tools/javac/code/Types.java	Wed Jun 23 16:44:15 2010 -0700
|+++ openjdk/langtools/src/share/classes/com/sun/tools/javac/code/Types.java	Fri Sep 10 17:47:33 2010 +0100
--------------------------
Patching file openjdk/langtools/src/share/classes/com/sun/tools/javac/code/Types.java using Plan A...
Hunk #1 succeeded at 335 (offset 4 lines).
Hunk #2 succeeded at 2778 (offset 4 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 27f03394a69d -r c5fe15e03287 src/share/classes/com/sun/tools/javac/comp/Check.java
|--- openjdk.orig/langtools/src/share/classes/com/sun/tools/javac/comp/Check.java	Wed Jun 23 16:44:15 2010 -0700
|+++ openjdk/langtools/src/share/classes/com/sun/tools/javac/comp/Check.java	Fri Sep 10 17:47:33 2010 +0100
--------------------------
Patching file openjdk/langtools/src/share/classes/com/sun/tools/javac/comp/Check.java using Plan A...
Hunk #1 succeeded at 383.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 27f03394a69d -r c5fe15e03287 src/share/classes/com/sun/tools/javac/comp/Infer.java
|--- openjdk.orig/langtools/src/share/classes/com/sun/tools/javac/comp/Infer.java	Wed Jun 23 16:44:15 2010 -0700
|+++ openjdk/langtools/src/share/classes/com/sun/tools/javac/comp/Infer.java	Fri Sep 10 17:47:33 2010 +0100
--------------------------
Patching file openjdk/langtools/src/share/classes/com/sun/tools/javac/comp/Infer.java using Plan A...
Hunk #1 succeeded at 29.
Hunk #2 succeeded at 51.
Hunk #3 succeeded at 64.
Hunk #4 succeeded at 257.
Hunk #5 succeeded at 283.
Hunk #6 succeeded at 291.
Hunk #7 succeeded at 334.
Hunk #8 succeeded at 379.
Hunk #9 succeeded at 422.
Hunk #10 succeeded at 439.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 27f03394a69d -r c5fe15e03287 src/share/classes/com/sun/tools/javac/comp/Resolve.java
|--- openjdk.orig/langtools/src/share/classes/com/sun/tools/javac/comp/Resolve.java	Wed Jun 23 16:44:15 2010 -0700
|+++ openjdk/langtools/src/share/classes/com/sun/tools/javac/comp/Resolve.java	Fri Sep 10 17:47:33 2010 +0100
--------------------------
Patching file openjdk/langtools/src/share/classes/com/sun/tools/javac/comp/Resolve.java using Plan A...
Hunk #1 succeeded at 279.
Hunk #2 succeeded at 350.
Hunk #3 succeeded at 562.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 27f03394a69d -r c5fe15e03287 src/share/classes/com/sun/tools/javac/resources/compiler.properties
|--- openjdk.orig/langtools/src/share/classes/com/sun/tools/javac/resources/compiler.properties	Wed Jun 23 16:44:15 2010 -0700
|+++ openjdk/langtools/src/share/classes/com/sun/tools/javac/resources/compiler.properties	Fri Sep 10 17:47:33 2010 +0100
--------------------------
Patching file openjdk/langtools/src/share/classes/com/sun/tools/javac/resources/compiler.properties using Plan A...
Hunk #1 succeeded at 454.
Hunk #2 succeeded at 962.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 27f03394a69d -r c5fe15e03287 test/tools/javac/generics/inference/6302954/T6476073.java
|--- openjdk.orig/langtools/test/tools/javac/generics/inference/6302954/T6476073.java	Wed Jun 23 16:44:15 2010 -0700
|+++ openjdk/langtools/test/tools/javac/generics/inference/6302954/T6476073.java	Fri Sep 10 17:47:33 2010 +0100
--------------------------
Patching file openjdk/langtools/test/tools/javac/generics/inference/6302954/T6476073.java using Plan A...
Hunk #1 succeeded at 25.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 27f03394a69d -r c5fe15e03287 test/tools/javac/generics/inference/6638712/T6638712a.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712a.java	Fri Sep 10 17:47:33 2010 +0100
--------------------------
(Creating file openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712a.java...)
Patching file openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712a.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 27f03394a69d -r c5fe15e03287 test/tools/javac/generics/inference/6638712/T6638712a.out
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712a.out	Fri Sep 10 17:47:33 2010 +0100
--------------------------
(Creating file openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712a.out...)
Patching file openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712a.out using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 27f03394a69d -r c5fe15e03287 test/tools/javac/generics/inference/6638712/T6638712b.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712b.java	Fri Sep 10 17:47:33 2010 +0100
--------------------------
(Creating file openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712b.java...)
Patching file openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712b.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 27f03394a69d -r c5fe15e03287 test/tools/javac/generics/inference/6638712/T6638712b.out
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712b.out	Fri Sep 10 17:47:33 2010 +0100
--------------------------
(Creating file openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712b.out...)
Patching file openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712b.out using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 27f03394a69d -r c5fe15e03287 test/tools/javac/generics/inference/6638712/T6638712c.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712c.java	Fri Sep 10 17:47:33 2010 +0100
--------------------------
(Creating file openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712c.java...)
Patching file openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712c.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 27f03394a69d -r c5fe15e03287 test/tools/javac/generics/inference/6638712/T6638712c.out
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712c.out	Fri Sep 10 17:47:33 2010 +0100
--------------------------
(Creating file openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712c.out...)
Patching file openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712c.out using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 27f03394a69d -r c5fe15e03287 test/tools/javac/generics/inference/6638712/T6638712d.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712d.java	Fri Sep 10 17:47:33 2010 +0100
--------------------------
(Creating file openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712d.java...)
Patching file openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712d.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 27f03394a69d -r c5fe15e03287 test/tools/javac/generics/inference/6638712/T6638712d.out
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712d.out	Fri Sep 10 17:47:33 2010 +0100
--------------------------
(Creating file openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712d.out...)
Patching file openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712d.out using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 27f03394a69d -r c5fe15e03287 test/tools/javac/generics/inference/6638712/T6638712e.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712e.java	Fri Sep 10 17:47:33 2010 +0100
--------------------------
(Creating file openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712e.java...)
Patching file openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712e.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 27f03394a69d -r c5fe15e03287 test/tools/javac/generics/inference/6638712/T6638712e.out
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712e.out	Fri Sep 10 17:47:33 2010 +0100
--------------------------
(Creating file openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712e.out...)
Patching file openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712e.out using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/openjdk/6650759-missing_inference.patch
Applying patches/openjdk/6650759-missing_inference.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/langtools/src/share/classes/com/sun/tools/javac/code/Type.java openjdk/langtools/src/share/classes/com/sun/tools/javac/code/Type.java
|--- openjdk.orig/langtools/src/share/classes/com/sun/tools/javac/code/Type.java	2010-09-09 20:03:34.000000000 +0100
|+++ openjdk/langtools/src/share/classes/com/sun/tools/javac/code/Type.java	2010-09-09 20:24:56.236744893 +0100
--------------------------
Patching file openjdk/langtools/src/share/classes/com/sun/tools/javac/code/Type.java using Plan A...
Hunk #1 succeeded at 1063.
Hunk #2 succeeded at 1076.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/langtools/src/share/classes/com/sun/tools/javac/comp/Infer.java openjdk/langtools/src/share/classes/com/sun/tools/javac/comp/Infer.java
|--- openjdk.orig/langtools/src/share/classes/com/sun/tools/javac/comp/Infer.java	2010-09-09 20:03:34.000000000 +0100
|+++ openjdk/langtools/src/share/classes/com/sun/tools/javac/comp/Infer.java	2010-09-09 20:25:15.752817376 +0100
--------------------------
Patching file openjdk/langtools/src/share/classes/com/sun/tools/javac/comp/Infer.java using Plan A...
Hunk #1 succeeded at 29.
Hunk #2 succeeded at 52.
Hunk #3 succeeded at 67.
Hunk #4 succeeded at 263.
Hunk #5 succeeded at 291.
Hunk #6 succeeded at 367.
Hunk #7 succeeded at 380.
Hunk #8 succeeded at 401.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/langtools/test/tools/javac/generics/inference/6302954/T6476073.java openjdk/langtools/test/tools/javac/generics/inference/6302954/T6476073.java
|--- openjdk.orig/langtools/test/tools/javac/generics/inference/6302954/T6476073.java	2010-09-09 20:03:34.000000000 +0100
|+++ openjdk/langtools/test/tools/javac/generics/inference/6302954/T6476073.java	2010-09-09 20:24:56.236744893 +0100
--------------------------
Patching file openjdk/langtools/test/tools/javac/generics/inference/6302954/T6476073.java using Plan A...
Hunk #1 succeeded at 25.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/langtools/test/tools/javac/generics/inference/6650759/T6650759a.java openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759a.java
|--- openjdk.orig/langtools/test/tools/javac/generics/inference/6650759/T6650759a.java	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759a.java	2010-09-09 20:24:56.248744934 +0100
--------------------------
(Creating file openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759a.java...)
Patching file openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759a.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/langtools/test/tools/javac/generics/inference/6650759/T6650759b.java openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759b.java
|--- openjdk.orig/langtools/test/tools/javac/generics/inference/6650759/T6650759b.java	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759b.java	2010-09-09 20:24:56.248744934 +0100
--------------------------
(Creating file openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759b.java...)
Patching file openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759b.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/langtools/test/tools/javac/generics/inference/6650759/T6650759c.java openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759c.java
|--- openjdk.orig/langtools/test/tools/javac/generics/inference/6650759/T6650759c.java	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759c.java	2010-09-09 20:24:56.248744934 +0100
--------------------------
(Creating file openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759c.java...)
Patching file openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759c.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/langtools/test/tools/javac/generics/inference/6650759/T6650759d.java openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759d.java
|--- openjdk.orig/langtools/test/tools/javac/generics/inference/6650759/T6650759d.java	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759d.java	2010-09-09 20:24:56.248744934 +0100
--------------------------
(Creating file openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759d.java...)
Patching file openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759d.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/langtools/test/tools/javac/generics/inference/6650759/T6650759e.java openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759e.java
|--- openjdk.orig/langtools/test/tools/javac/generics/inference/6650759/T6650759e.java	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759e.java	2010-09-09 20:24:56.248744934 +0100
--------------------------
(Creating file openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759e.java...)
Patching file openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759e.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/langtools/test/tools/javac/generics/inference/6650759/T6650759f.java openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759f.java
|--- openjdk.orig/langtools/test/tools/javac/generics/inference/6650759/T6650759f.java	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759f.java	2010-09-09 20:24:56.248744934 +0100
--------------------------
(Creating file openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759f.java...)
Patching file openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759f.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/langtools/test/tools/javac/generics/inference/6650759/T6650759g.java openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759g.java
|--- openjdk.orig/langtools/test/tools/javac/generics/inference/6650759/T6650759g.java	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759g.java	2010-09-09 20:24:56.248744934 +0100
--------------------------
(Creating file openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759g.java...)
Patching file openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759g.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/langtools/test/tools/javac/generics/inference/6650759/T6650759h.java openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759h.java
|--- openjdk.orig/langtools/test/tools/javac/generics/inference/6650759/T6650759h.java	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759h.java	2010-09-09 20:24:56.248744934 +0100
--------------------------
(Creating file openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759h.java...)
Patching file openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759h.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/langtools/test/tools/javac/generics/inference/6650759/T6650759i.java openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759i.java
|--- openjdk.orig/langtools/test/tools/javac/generics/inference/6650759/T6650759i.java	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759i.java	2010-09-09 20:24:56.248744934 +0100
--------------------------
(Creating file openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759i.java...)
Patching file openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759i.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/langtools/test/tools/javac/generics/inference/6650759/T6650759j.java openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759j.java
|--- openjdk.orig/langtools/test/tools/javac/generics/inference/6650759/T6650759j.java	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759j.java	2010-09-09 20:24:56.248744934 +0100
--------------------------
(Creating file openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759j.java...)
Patching file openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759j.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/langtools/test/tools/javac/generics/inference/6650759/T6650759k.java openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759k.java
|--- openjdk.orig/langtools/test/tools/javac/generics/inference/6650759/T6650759k.java	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759k.java	2010-09-09 20:24:56.248744935 +0100
--------------------------
(Creating file openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759k.java...)
Patching file openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759k.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/langtools/test/tools/javac/generics/inference/6650759/T6650759l.java openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759l.java
|--- openjdk.orig/langtools/test/tools/javac/generics/inference/6650759/T6650759l.java	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759l.java	2010-09-09 20:24:56.248744935 +0100
--------------------------
(Creating file openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759l.java...)
Patching file openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759l.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/langtools/test/tools/javac/generics/inference/6650759/T6650759m.java openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759m.java
|--- openjdk.orig/langtools/test/tools/javac/generics/inference/6650759/T6650759m.java	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759m.java	2010-09-09 20:24:56.248744935 +0100
--------------------------
(Creating file openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759m.java...)
Patching file openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759m.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/langtools/test/tools/javac/generics/inference/6650759/T6650759m.out openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759m.out
|--- openjdk.orig/langtools/test/tools/javac/generics/inference/6650759/T6650759m.out	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759m.out	2010-09-09 20:24:56.248744935 +0100
--------------------------
(Creating file openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759m.out...)
Patching file openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759m.out using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/numa_on_early_glibc.patch
Applying patches/numa_on_early_glibc.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk.orig/hotspot/src/os/linux/vm/os_linux.cpp	2010-09-14 15:30:59.000000000 +0100
|+++ openjdk/hotspot/src/os/linux/vm/os_linux.cpp	2010-09-14 17:45:54.000000000 +0100
--------------------------
Patching file openjdk/hotspot/src/os/linux/vm/os_linux.cpp using Plan A...
Hunk #1 succeeded at 117 with fuzz 2 (offset 63 lines).
Hunk #2 succeeded at 2485 (offset 67 lines).
Hunk #3 succeeded at 2517 (offset 76 lines).
done
Checking patches/jtreg-international-fonts.patch
Applying patches/jtreg-international-fonts.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- /dev/null	2011-07-20 10:54:36.268271016 +0200
|+++ openjdk/jdk/test/java/awt/font/InternationalFonts/InternationalFontsRendering.java	2011-09-16 17:18:14.000000000 +0200
--------------------------
(Creating file openjdk/jdk/test/java/awt/font/InternationalFonts/InternationalFontsRendering.java...)
Patching file openjdk/jdk/test/java/awt/font/InternationalFonts/InternationalFontsRendering.java using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/f14-fonts.patch
Applying patches/f14-fonts.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/jdk/make/sun/awt/Makefile	2010-11-04 09:52:49.583434000 +0100
|+++ openjdk/jdk/make/sun/awt/Makefile	2010-11-04 16:50:14.091688769 +0100
--------------------------
Patching file openjdk/jdk/make/sun/awt/Makefile using Plan A...
Hunk #1 succeeded at 388 (offset 1 line).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|
|--- openjdk/jdk/src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.11.properties	2010-11-04 11:06:26.695428114 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.11.properties	2010-11-04 11:19:45.133587953 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.11.properties using Plan A...
Hunk #1 succeeded at 35.
Hunk #2 succeeded at 52.
Hunk #3 succeeded at 69.
Hunk #4 succeeded at 86.
Hunk #5 succeeded at 103.
Hunk #6 succeeded at 120.
Hunk #7 succeeded at 137.
Hunk #8 succeeded at 154.
Hunk #9 succeeded at 171.
Hunk #10 succeeded at 188.
Hunk #11 succeeded at 205.
Hunk #12 succeeded at 222.
Hunk #13 succeeded at 239.
Hunk #14 succeeded at 256.
Hunk #15 succeeded at 273.
Hunk #16 succeeded at 290.
Hunk #17 succeeded at 307.
Hunk #18 succeeded at 324.
Hunk #19 succeeded at 341.
Hunk #20 succeeded at 358.
Hunk #21 succeeded at 396.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|
|--- openjdk/jdk/src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.12.properties	2010-11-04 11:06:26.695428114 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.12.properties	2010-11-04 11:19:45.133587953 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.12.properties using Plan A...
Hunk #1 succeeded at 35.
Hunk #2 succeeded at 52.
Hunk #3 succeeded at 69.
Hunk #4 succeeded at 86.
Hunk #5 succeeded at 103.
Hunk #6 succeeded at 120.
Hunk #7 succeeded at 137.
Hunk #8 succeeded at 154.
Hunk #9 succeeded at 171.
Hunk #10 succeeded at 188.
Hunk #11 succeeded at 205.
Hunk #12 succeeded at 222.
Hunk #13 succeeded at 239.
Hunk #14 succeeded at 256.
Hunk #15 succeeded at 273.
Hunk #16 succeeded at 290.
Hunk #17 succeeded at 307.
Hunk #18 succeeded at 324.
Hunk #19 succeeded at 341.
Hunk #20 succeeded at 358.
Hunk #21 succeeded at 396.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/jdk/src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.properties	2010-11-04 11:06:26.695428114 +0100
|+++ openjdk/jdk/src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.properties	2010-11-04 11:06:25.602455633 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.properties using Plan A...
Hunk #1 succeeded at 35.
Hunk #2 succeeded at 52.
Hunk #3 succeeded at 69.
Hunk #4 succeeded at 86.
Hunk #5 succeeded at 103.
Hunk #6 succeeded at 120.
Hunk #7 succeeded at 137.
Hunk #8 succeeded at 154.
Hunk #9 succeeded at 171.
Hunk #10 succeeded at 188.
Hunk #11 succeeded at 205.
Hunk #12 succeeded at 222.
Hunk #13 succeeded at 239.
Hunk #14 succeeded at 256.
Hunk #15 succeeded at 273.
Hunk #16 succeeded at 290.
Hunk #17 succeeded at 307.
Hunk #18 succeeded at 324.
Hunk #19 succeeded at 341.
Hunk #20 succeeded at 358.
Hunk #21 succeeded at 396.
done
Checking patches/jtreg-T6638712-fix.patch
Applying patches/jtreg-T6638712-fix.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk-old/langtools/test/tools/javac/generics/inference/6638712/T6638712a.out	2010-11-30 14:44:29.000000000 +0100
|+++ openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712a.out	2010-11-30 15:27:57.000000000 +0100
--------------------------
Patching file openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712a.out using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk-old/langtools/test/tools/javac/generics/inference/6638712/T6638712b.out	2010-11-30 14:44:29.000000000 +0100
|+++ openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712b.out	2010-11-30 15:27:58.000000000 +0100
--------------------------
Patching file openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712b.out using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk-old/langtools/test/tools/javac/generics/inference/6638712/T6638712c.out	2010-11-30 14:44:29.000000000 +0100
|+++ openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712c.out	2010-11-30 15:27:59.000000000 +0100
--------------------------
Patching file openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712c.out using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk-old/langtools/test/tools/javac/generics/inference/6638712/T6638712d.out	2010-11-30 14:44:29.000000000 +0100
|+++ openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712d.out	2010-11-30 15:28:01.000000000 +0100
--------------------------
Patching file openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712d.out using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk-old/langtools/test/tools/javac/generics/inference/6638712/T6638712e.out	2010-11-30 14:44:29.000000000 +0100
|+++ openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712e.out	2010-11-30 15:28:02.000000000 +0100
--------------------------
Patching file openjdk/langtools/test/tools/javac/generics/inference/6638712/T6638712e.out using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/jtreg-T6650759m-fix.patch
Applying patches/jtreg-T6650759m-fix.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk-old/langtools/test/tools/javac/generics/inference/6650759/T6650759m.out	2010-12-03 16:08:35.000000000 +0100
|+++ openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759m.out	2010-12-03 16:12:08.000000000 +0100
--------------------------
Patching file openjdk/langtools/test/tools/javac/generics/inference/6650759/T6650759m.out using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/openjdk/7003777-bad-html-entity-parse.patch
Applying patches/openjdk/7003777-bad-html-entity-parse.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -U5 -r --new-file openjdk.old/jdk/src/share/classes/javax/swing/text/html/parser/Parser.java openjdk/jdk/src/share/classes/javax/swing/text/html/parser/Parser.java
|--- openjdk.old/jdk/src/share/classes/javax/swing/text/html/parser/Parser.java	2010-11-30 16:41:02.011095918 -0500
|+++ openjdk/jdk/src/share/classes/javax/swing/text/html/parser/Parser.java	2010-11-30 16:23:10.068090762 -0500
--------------------------
Patching file openjdk/jdk/src/share/classes/javax/swing/text/html/parser/Parser.java using Plan A...
Hunk #1 succeeded at 966.
Hunk #2 succeeded at 990.
Hunk #3 succeeded at 1011.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -U5 -r --new-file openjdk.old/jdk/test/javax/swing/text/html/Test7003777.java openjdk/jdk/test/javax/swing/text/html/Test7003777.java
|--- openjdk.old/jdk/test/javax/swing/text/html/Test7003777.java	1969-12-31 19:00:00.000000000 -0500
|+++ openjdk/jdk/test/javax/swing/text/html/Test7003777.java	2010-11-30 16:16:13.419104648 -0500
--------------------------
(Creating file openjdk/jdk/test/javax/swing/text/html/Test7003777.java...)
Patching file openjdk/jdk/test/javax/swing/text/html/Test7003777.java using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/jtreg-6929067-fix.patch
Applying patches/jtreg-6929067-fix.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk-old/hotspot/test/runtime/6929067/Test6929067.sh	2010-10-08 22:29:24.000000000 +0200
|+++ openjdk/hotspot/test/runtime/6929067/Test6929067.sh	2010-12-08 13:45:18.000000000 +0100
--------------------------
Patching file openjdk/hotspot/test/runtime/6929067/Test6929067.sh using Plan A...
Hunk #1 succeeded at 42.
Hunk #2 succeeded at 79.
done
Checking patches/rendering-engine-tests.patch
Applying patches/rendering-engine-tests.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nr --unified=5 ./openjdk.old/jdk/test/sun/java2d/pisces/Renderer/RenderingEngineTest.java ./openjdk/jdk/test/sun/java2d/pisces/Renderer/RenderingEngineTest.java
|--- ./openjdk.old/jdk/test/sun/java2d/pisces/Renderer/RenderingEngineTest.java	1969-12-31 19:00:00.000000000 -0500
|+++ ./openjdk/jdk/test/sun/java2d/pisces/Renderer/RenderingEngineTest.java	2010-12-15 15:57:11.881597163 -0500
--------------------------
(Creating file ./openjdk/jdk/test/sun/java2d/pisces/Renderer/RenderingEngineTest.java...)
Patching file ./openjdk/jdk/test/sun/java2d/pisces/Renderer/RenderingEngineTest.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nr --unified=5 ./openjdk.old/jdk/test/sun/java2d/pisces/Renderer/Test661554.java ./openjdk/jdk/test/sun/java2d/pisces/Renderer/Test661554.java
|--- ./openjdk.old/jdk/test/sun/java2d/pisces/Renderer/Test661554.java	1969-12-31 19:00:00.000000000 -0500
|+++ ./openjdk/jdk/test/sun/java2d/pisces/Renderer/Test661554.java	2010-12-15 15:57:11.881597163 -0500
--------------------------
(Creating file ./openjdk/jdk/test/sun/java2d/pisces/Renderer/Test661554.java...)
Patching file ./openjdk/jdk/test/sun/java2d/pisces/Renderer/Test661554.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nr --unified=5 ./openjdk.old/jdk/test/sun/java2d/pisces/Renderer/Test6967433.java ./openjdk/jdk/test/sun/java2d/pisces/Renderer/Test6967433.java
|--- ./openjdk.old/jdk/test/sun/java2d/pisces/Renderer/Test6967433.java	1969-12-31 19:00:00.000000000 -0500
|+++ ./openjdk/jdk/test/sun/java2d/pisces/Renderer/Test6967433.java	2010-12-15 15:57:11.882597017 -0500
--------------------------
(Creating file ./openjdk/jdk/test/sun/java2d/pisces/Renderer/Test6967433.java...)
Patching file ./openjdk/jdk/test/sun/java2d/pisces/Renderer/Test6967433.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nr --unified=5 ./openjdk.old/jdk/test/sun/java2d/pisces/Renderer/Test6967434.java ./openjdk/jdk/test/sun/java2d/pisces/Renderer/Test6967434.java
|--- ./openjdk.old/jdk/test/sun/java2d/pisces/Renderer/Test6967434.java	1969-12-31 19:00:00.000000000 -0500
|+++ ./openjdk/jdk/test/sun/java2d/pisces/Renderer/Test6967434.java	2010-12-15 15:57:11.881597163 -0500
--------------------------
(Creating file ./openjdk/jdk/test/sun/java2d/pisces/Renderer/Test6967434.java...)
Patching file ./openjdk/jdk/test/sun/java2d/pisces/Renderer/Test6967434.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nr --unified=5 ./openjdk.old/jdk/test/sun/java2d/pisces/Renderer/Test6967436.java ./openjdk/jdk/test/sun/java2d/pisces/Renderer/Test6967436.java
|--- ./openjdk.old/jdk/test/sun/java2d/pisces/Renderer/Test6967436.java	1969-12-31 19:00:00.000000000 -0500
|+++ ./openjdk/jdk/test/sun/java2d/pisces/Renderer/Test6967436.java	2010-12-15 15:57:11.882597017 -0500
--------------------------
(Creating file ./openjdk/jdk/test/sun/java2d/pisces/Renderer/Test6967436.java...)
Patching file ./openjdk/jdk/test/sun/java2d/pisces/Renderer/Test6967436.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nr --unified=5 ./openjdk.old/jdk/test/sun/java2d/pisces/Renderer/Test6976265.java ./openjdk/jdk/test/sun/java2d/pisces/Renderer/Test6976265.java
|--- ./openjdk.old/jdk/test/sun/java2d/pisces/Renderer/Test6976265.java	1969-12-31 19:00:00.000000000 -0500
|+++ ./openjdk/jdk/test/sun/java2d/pisces/Renderer/Test6976265.java	2010-12-15 15:57:11.881597163 -0500
--------------------------
(Creating file ./openjdk/jdk/test/sun/java2d/pisces/Renderer/Test6976265.java...)
Patching file ./openjdk/jdk/test/sun/java2d/pisces/Renderer/Test6976265.java using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/openjdk/6800846-printing-quality.patch
Applying patches/openjdk/6800846-printing-quality.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -U5 -r --new-file openjdk.old/jdk/src/share/native/sun/awt/image/dither.c openjdk/jdk/src/share/native/sun/awt/image/dither.c
|--- openjdk.old/jdk/src/share/native/sun/awt/image/dither.c	2010-12-20 13:07:38.305283324 -0500
|+++ openjdk/jdk/src/share/native/sun/awt/image/dither.c	2010-12-20 13:06:37.348012435 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/dither.c using Plan A...
Hunk #1 succeeded at 167.
Hunk #2 succeeded at 187.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -U5 -r --new-file openjdk.old/jdk/test/sun/awt/image/DrawByteBinary.java openjdk/jdk/test/sun/awt/image/DrawByteBinary.java
|--- openjdk.old/jdk/test/sun/awt/image/DrawByteBinary.java	1969-12-31 19:00:00.000000000 -0500
|+++ openjdk/jdk/test/sun/awt/image/DrawByteBinary.java	2010-12-20 13:05:48.338287585 -0500
--------------------------
(Creating file openjdk/jdk/test/sun/awt/image/DrawByteBinary.java...)
Patching file openjdk/jdk/test/sun/awt/image/DrawByteBinary.java using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/rh661505-jpeg.patch
Applying patches/rh661505-jpeg.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/jdk/src/share/native/sun/awt/image/jpeg/imageioJPEG.c.old	2010-12-24 13:20:49.444589072 -0500
|+++ openjdk/jdk/src/share/native/sun/awt/image/jpeg/imageioJPEG.c	2010-12-24 13:21:58.059463767 -0500
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/image/jpeg/imageioJPEG.c using Plan A...
Hunk #1 succeeded at 1489 (offset 1 line).
Hunk #2 succeeded at 1544 (offset 1 line).
Hunk #3 succeeded at 1605 (offset 1 line).
done
Checking patches/6703377-freetypescaler.patch
Applying patches/6703377-freetypescaler.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk.orig/jdk/src/share/native/sun/font/freetypeScaler.c	2010-10-15 15:19:35.000000000 +0200
|+++ openjdk/jdk/src/share/native/sun/font/freetypeScaler.c	2010-10-15 15:19:35.000000000 +0200
--------------------------
Patching file openjdk/jdk/src/share/native/sun/font/freetypeScaler.c using Plan A...
Hunk #1 succeeded at 978 (offset -1 lines).
done
Checking patches/ia64-fix.patch
Applying patches/ia64-fix.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/hotspot/src/share/vm/opto/connode.cpp~	2010-10-08 20:29:24.000000000 +0000
|+++ openjdk/hotspot/src/share/vm/opto/connode.cpp	2010-11-29 07:57:22.000000000 +0000
--------------------------
Patching file openjdk/hotspot/src/share/vm/opto/connode.cpp using Plan A...
Hunk #1 succeeded at 721 (offset 9 lines).
done
Checking patches/openjdk/6642612-filechooser_button_sizes.patch
Applying patches/openjdk/6642612-filechooser_button_sizes.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User rupashka
|# Date 1209546061 -14400
|# Node ID 9a322f3dccd8bf3ab5726ec18fbaa0131938f2c4
|# Parent  eca2e5716b86c31a2f6421473bcee3fec30a500f
|6642612: JFileChooser approve buttons should use Open and Save text (GTK)
|Summary: In FileChooser under GTK LaF "Ok" and "Cancel" buttons were made with the same size
|Reviewed-by: peterz
|
|diff -r eca2e5716b86 -r 9a322f3dccd8 src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java
|--- openjdk/jdk/src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java	Wed Apr 30 12:32:05 2008 +0400
|+++ openjdk/jdk/src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java	Wed Apr 30 13:01:01 2008 +0400
--------------------------
Patching file openjdk/jdk/src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java using Plan A...
Hunk #1 succeeded at 98 (offset 1 line).
Hunk #2 succeeded at 123 (offset 1 line).
Hunk #3 succeeded at 715 (offset 9 lines).
Hunk #4 succeeded at 1107 (offset -1 lines).
done
Checking patches/jtreg-international-fonts-styles.patch
Applying patches/jtreg-international-fonts-styles.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- /dev/null	2010-06-29 11:10:08.737208357 +0200
|+++ openjdk/jdk/test/java/awt/font/InternationalFonts/InternationalFontsStyles.java	2011-01-17 17:06:44.452369000 +0100
--------------------------
(Creating file openjdk/jdk/test/java/awt/font/InternationalFonts/InternationalFontsStyles.java...)
Patching file openjdk/jdk/test/java/awt/font/InternationalFonts/InternationalFontsStyles.java using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/openjdk/6736649-text_bearings.patch
Applying patches/openjdk/6736649-text_bearings.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User mlapshin
|# Date 1219738583 -14400
|# Node ID e78c2f17a60646b8198279b2f676712094b833a0
|# Parent  c9d407ab230941d41025428b25bc5d787cf7c18f
|6736649: test/closed/javax/swing/JMenuItem/6458123/ManualBug6458123.java fails on Linux
|Summary: Now text bearings are taken into account when labelRect width is calculated
|Reviewed-by: alexp
|
|diff -r c9d407ab2309 -r e78c2f17a606 src/share/classes/javax/swing/plaf/synth/SynthMenuItemLayoutHelper.java
|--- openjdk/jdk/src/share/classes/javax/swing/plaf/synth/SynthMenuItemLayoutHelper.java	Tue Aug 12 17:59:58 2008 -0700
|+++ openjdk/jdk/src/share/classes/javax/swing/plaf/synth/SynthMenuItemLayoutHelper.java	Tue Aug 26 12:16:23 2008 +0400
--------------------------
Patching file openjdk/jdk/src/share/classes/javax/swing/plaf/synth/SynthMenuItemLayoutHelper.java using Plan A...
Hunk #1 succeeded at 136.
Hunk #2 succeeded at 195.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r c9d407ab2309 -r e78c2f17a606 src/share/classes/sun/swing/MenuItemLayoutHelper.java
|--- openjdk/jdk/src/share/classes/sun/swing/MenuItemLayoutHelper.java	Tue Aug 12 17:59:58 2008 -0700
|+++ openjdk/jdk/src/share/classes/sun/swing/MenuItemLayoutHelper.java	Tue Aug 26 12:16:23 2008 +0400
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/swing/MenuItemLayoutHelper.java using Plan A...
Hunk #1 succeeded at 83.
Hunk #2 succeeded at 146.
Hunk #3 succeeded at 155.
Hunk #4 succeeded at 313.
Hunk #5 succeeded at 792 (offset 37 lines).
Hunk #6 succeeded at 1154 (offset 37 lines).
done
Checking patches/openjdk/6797139-jbutton_truncation.patch
Applying patches/openjdk/6797139-jbutton_truncation.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User alexp
|# Date 1251899239 -14400
|# Node ID 281fbd82a971f05fcf6f2c31cfe7db7ef74909e9
|# Parent  935814bd43a62d1b2c6871f0298c5b59fbf54428
|6797139: JButton title is truncating for some strings irrespective of preferred size.
|Reviewed-by: peterz
|
|diff -r 935814bd43a6 -r 281fbd82a971 src/share/classes/javax/swing/SwingUtilities.java
|--- openjdk/jdk/src/share/classes/javax/swing/SwingUtilities.java	Tue Sep 01 18:51:15 2009 +0400
|+++ openjdk/jdk/src/share/classes/javax/swing/SwingUtilities.java	Wed Sep 02 17:47:19 2009 +0400
--------------------------
Patching file openjdk/jdk/src/share/classes/javax/swing/SwingUtilities.java using Plan A...
Hunk #1 succeeded at 1000 (offset 1 line).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 935814bd43a6 -r 281fbd82a971 src/share/classes/javax/swing/plaf/synth/SynthMenuItemLayoutHelper.java
|--- openjdk/jdk/src/share/classes/javax/swing/plaf/synth/SynthMenuItemLayoutHelper.java	Tue Sep 01 18:51:15 2009 +0400
|+++ openjdk/jdk/src/share/classes/javax/swing/plaf/synth/SynthMenuItemLayoutHelper.java	Wed Sep 02 17:47:19 2009 +0400
--------------------------
Patching file openjdk/jdk/src/share/classes/javax/swing/plaf/synth/SynthMenuItemLayoutHelper.java using Plan A...
Hunk #1 succeeded at 195.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 935814bd43a6 -r 281fbd82a971 src/share/classes/sun/swing/MenuItemLayoutHelper.java
|--- openjdk/jdk/src/share/classes/sun/swing/MenuItemLayoutHelper.java	Tue Sep 01 18:51:15 2009 +0400
|+++ openjdk/jdk/src/share/classes/sun/swing/MenuItemLayoutHelper.java	Wed Sep 02 17:47:19 2009 +0400
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/swing/MenuItemLayoutHelper.java using Plan A...
Hunk #1 succeeded at 84.
Hunk #2 succeeded at 156.
Hunk #3 succeeded at 167.
Hunk #4 succeeded at 302.
Hunk #5 succeeded at 1147 (offset 37 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 935814bd43a6 -r 281fbd82a971 src/share/classes/sun/swing/SwingUtilities2.java
|--- openjdk/jdk/src/share/classes/sun/swing/SwingUtilities2.java	Tue Sep 01 18:51:15 2009 +0400
|+++ openjdk/jdk/src/share/classes/sun/swing/SwingUtilities2.java	Wed Sep 02 17:47:19 2009 +0400
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/swing/SwingUtilities2.java using Plan A...
Hunk #1 succeeded at 27.
Hunk #2 succeeded at 69 with fuzz 2 (offset -8 lines).
Hunk #3 succeeded at 185 (offset -3 lines).
Hunk #4 succeeded at 227 (offset -8 lines).
Hunk #5 succeeded at 242 (offset -3 lines).
Hunk #6 succeeded at 250 (offset -8 lines).
Hunk #7 succeeded at 995 (offset -8 lines).
Hunk #8 succeeded at 1077 (offset -8 lines).
Hunk #9 succeeded at 1085 (offset -8 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 935814bd43a6 -r 281fbd82a971 test/javax/swing/SwingUtilities/6797139/bug6797139.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/javax/swing/SwingUtilities/6797139/bug6797139.java	Wed Sep 02 17:47:19 2009 +0400
--------------------------
(Creating file openjdk/jdk/test/javax/swing/SwingUtilities/6797139/bug6797139.java...)
Patching file openjdk/jdk/test/javax/swing/SwingUtilities/6797139/bug6797139.java using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/openjdk/6883341-text_bearing_exception.patch
Applying patches/openjdk/6883341-text_bearing_exception.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User alexp
|# Date 1253541489 -14400
|# Node ID 9d78c3d9def2044404e678f3508dd0bb25946fd2
|# Parent  fa71ca7a36555ea20de4669a3959bb0ba226d9a8
|6883341: SWAT: jdk7-b72 swat build(2009-09-17) threw exceptions when running Java2D demo by clicking Paint ta
|Reviewed-by: peterz
|
|diff -r fa71ca7a3655 -r 9d78c3d9def2 src/share/classes/sun/swing/SwingUtilities2.java
|--- openjdk/jdk/src/share/classes/sun/swing/SwingUtilities2.java	Mon Sep 21 01:26:57 2009 -0700
|+++ openjdk/jdk/src/share/classes/sun/swing/SwingUtilities2.java	Mon Sep 21 17:58:09 2009 +0400
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/swing/SwingUtilities2.java using Plan A...
Hunk #1 succeeded at 226 (offset -24 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r fa71ca7a3655 -r 9d78c3d9def2 test/javax/swing/JMenuItem/6883341/bug6883341.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/javax/swing/JMenuItem/6883341/bug6883341.java	Mon Sep 21 17:58:09 2009 +0400
--------------------------
(Creating file openjdk/jdk/test/javax/swing/JMenuItem/6883341/bug6883341.java...)
Patching file openjdk/jdk/test/javax/swing/JMenuItem/6883341/bug6883341.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  Ignoring the trailing garbage.
done
Checking patches/jtreg-png-reader.patch
Applying patches/jtreg-png-reader.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nu old/AbstractImageProcessor.java PngReader/AbstractImageProcessor.java
|--- /dev/null	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/test/javax/imageio/plugins/png/PngReader/AbstractImageProcessor.java	2011-06-21 11:46:22.000000000 +0200
--------------------------
(Creating file openjdk/jdk/test/javax/imageio/plugins/png/PngReader/AbstractImageProcessor.java...)
Patching file openjdk/jdk/test/javax/imageio/plugins/png/PngReader/AbstractImageProcessor.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nu old/BrokenPngImageProcessor.java PngReader/BrokenPngImageProcessor.java
|--- /dev/null	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/test/javax/imageio/plugins/png/PngReader/BrokenPngImageProcessor.java	2011-01-28 17:47:13.000000000 +0100
--------------------------
(Creating file openjdk/jdk/test/javax/imageio/plugins/png/PngReader/BrokenPngImageProcessor.java...)
Patching file openjdk/jdk/test/javax/imageio/plugins/png/PngReader/BrokenPngImageProcessor.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nu old/GoodPngImageProcessor.java PngReader/GoodPngImageProcessor.java
|--- /dev/null	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/test/javax/imageio/plugins/png/PngReader/GoodPngImageProcessor.java	2011-01-28 17:47:17.000000000 +0100
--------------------------
(Creating file openjdk/jdk/test/javax/imageio/plugins/png/PngReader/GoodPngImageProcessor.java...)
Patching file openjdk/jdk/test/javax/imageio/plugins/png/PngReader/GoodPngImageProcessor.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- /dev/null	2011-03-28 09:47:44.855266162 +0200
|+++ openjdk/jdk/test/javax/imageio/plugins/png/PngReader/ImageCompareException.java	2011-06-21 11:32:11.000000000 +0200
--------------------------
(Creating file openjdk/jdk/test/javax/imageio/plugins/png/PngReader/ImageCompareException.java...)
Patching file openjdk/jdk/test/javax/imageio/plugins/png/PngReader/ImageCompareException.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- /dev/null	2011-03-28 09:47:44.855266162 +0200
|+++ openjdk/jdk/test/javax/imageio/plugins/png/PngReader/ImageReaderAndComparator.java	2011-06-21 11:48:38.123378000 +0200
--------------------------
(Creating file openjdk/jdk/test/javax/imageio/plugins/png/PngReader/ImageReaderAndComparator.java...)
Patching file openjdk/jdk/test/javax/imageio/plugins/png/PngReader/ImageReaderAndComparator.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- /dev/null	2011-03-28 09:47:44.855266162 +0200
|+++ openjdk/jdk/test/javax/imageio/plugins/png/PngReader/ImageReadException.java	2011-01-28 17:47:22.000000000 +0100
--------------------------
(Creating file openjdk/jdk/test/javax/imageio/plugins/png/PngReader/ImageReadException.java...)
Patching file openjdk/jdk/test/javax/imageio/plugins/png/PngReader/ImageReadException.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- /dev/null	2011-03-28 09:47:44.855266162 +0200
|+++ openjdk/jdk/test/javax/imageio/plugins/png/PngReader/PamImageReadException.java	2011-06-21 11:32:23.000000000 +0200
--------------------------
(Creating file openjdk/jdk/test/javax/imageio/plugins/png/PngReader/PamImageReadException.java...)
Patching file openjdk/jdk/test/javax/imageio/plugins/png/PngReader/PamImageReadException.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- /dev/null	2011-03-28 09:47:44.855266162 +0200
|+++ openjdk/jdk/test/javax/imageio/plugins/png/PngReader/pngsuite.doc	1998-04-05 17:02:03.000000000 +0200
--------------------------
(Creating file openjdk/jdk/test/javax/imageio/plugins/png/PngReader/pngsuite.doc...)
Patching file openjdk/jdk/test/javax/imageio/plugins/png/PngReader/pngsuite.doc using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/openjdk/4724552-CubicCurve2D.patch
Applying patches/openjdk/4724552-CubicCurve2D.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/jdk/src/share/classes/java/awt/geom/CubicCurve2D.java.old	2011-01-20 18:54:14.000000000 -0500
|+++ openjdk/jdk/src/share/classes/java/awt/geom/CubicCurve2D.java	2011-01-31 12:38:24.340733697 -0500
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/geom/CubicCurve2D.java using Plan A...
Hunk #1 succeeded at 1602.
done
Checking patches/openjdk/4493128-CubicCurve2D.patch
Applying patches/openjdk/4493128-CubicCurve2D.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/jdk/src/share/classes/java/awt/geom/CubicCurve2D.java.old	2011-01-31 12:38:24.340733697 -0500
|+++ openjdk/jdk/src/share/classes/java/awt/geom/CubicCurve2D.java	2011-01-31 12:54:27.462601773 -0500
--------------------------
Patching file openjdk/jdk/src/share/classes/java/awt/geom/CubicCurve2D.java using Plan A...
Hunk #1 succeeded at 1387.
done
Checking patches/openjdk/4645692-CubicCurve2D.solveCubic.patch
Applying patches/openjdk/4645692-CubicCurve2D.solveCubic.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nr --unified=3 ./openjdk.old/jdk/src/share/classes/java/awt/geom/CubicCurve2D.java ./openjdk/jdk/src/share/classes/java/awt/geom/CubicCurve2D.java
|--- ./openjdk.old/jdk/src/share/classes/java/awt/geom/CubicCurve2D.java	2011-02-01 10:52:21.560149275 -0500
|+++ ./openjdk/jdk/src/share/classes/java/awt/geom/CubicCurve2D.java	2011-02-01 10:52:37.112148647 -0500
--------------------------
Patching file ./openjdk/jdk/src/share/classes/java/awt/geom/CubicCurve2D.java using Plan A...
Hunk #1 succeeded at 31.
Hunk #2 succeeded at 1087.
Hunk #3 succeeded at 1377.
Hunk #4 succeeded at 1434.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nr --unified=3 ./openjdk.old/jdk/test/java/awt/geom/CubicCurve2D/ContainsTest.java ./openjdk/jdk/test/java/awt/geom/CubicCurve2D/ContainsTest.java
|--- ./openjdk.old/jdk/test/java/awt/geom/CubicCurve2D/ContainsTest.java	1969-12-31 19:00:00.000000000 -0500
|+++ ./openjdk/jdk/test/java/awt/geom/CubicCurve2D/ContainsTest.java	2011-02-01 10:54:07.105148995 -0500
--------------------------
(Creating file ./openjdk/jdk/test/java/awt/geom/CubicCurve2D/ContainsTest.java...)
Patching file ./openjdk/jdk/test/java/awt/geom/CubicCurve2D/ContainsTest.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nr --unified=3 ./openjdk.old/jdk/test/java/awt/geom/CubicCurve2D/IntersectsTest.java ./openjdk/jdk/test/java/awt/geom/CubicCurve2D/IntersectsTest.java
|--- ./openjdk.old/jdk/test/java/awt/geom/CubicCurve2D/IntersectsTest.java	1969-12-31 19:00:00.000000000 -0500
|+++ ./openjdk/jdk/test/java/awt/geom/CubicCurve2D/IntersectsTest.java	2011-02-01 10:54:07.105148995 -0500
--------------------------
(Creating file ./openjdk/jdk/test/java/awt/geom/CubicCurve2D/IntersectsTest.java...)
Patching file ./openjdk/jdk/test/java/awt/geom/CubicCurve2D/IntersectsTest.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nr --unified=3 ./openjdk.old/jdk/test/java/awt/geom/CubicCurve2D/SolveCubicTest.java ./openjdk/jdk/test/java/awt/geom/CubicCurve2D/SolveCubicTest.java
|--- ./openjdk.old/jdk/test/java/awt/geom/CubicCurve2D/SolveCubicTest.java	1969-12-31 19:00:00.000000000 -0500
|+++ ./openjdk/jdk/test/java/awt/geom/CubicCurve2D/SolveCubicTest.java	2011-02-01 10:54:07.105148995 -0500
--------------------------
(Creating file ./openjdk/jdk/test/java/awt/geom/CubicCurve2D/SolveCubicTest.java...)
Patching file ./openjdk/jdk/test/java/awt/geom/CubicCurve2D/SolveCubicTest.java using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/no-static-linking.patch
Applying patches/no-static-linking.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r f7afe7a5e086 make/common/shared/Compiler-gcc.gmk
|--- openjdk.orig/jdk/make/common/shared/Compiler-gcc.gmk	Fri Jan 21 16:21:28 2011 -0800
|+++ openjdk/jdk/make/common/shared/Compiler-gcc.gmk	Thu Feb 03 11:34:13 2011 +0000
--------------------------
Patching file openjdk/jdk/make/common/shared/Compiler-gcc.gmk using Plan A...
Hunk #1 succeeded at 61 with fuzz 2.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 9797bcda6c12 make/linux/makefiles/vm.make
|--- openjdk.orig/hotspot/make/linux/makefiles/vm.make	Fri Jan 21 16:20:02 2011 -0800
|+++ openjdk/hotspot/make/linux/makefiles/vm.make	Thu Feb 03 15:01:10 2011 +0000
--------------------------
Patching file openjdk/hotspot/make/linux/makefiles/vm.make using Plan A...
Hunk #1 succeeded at 208 (offset 71 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 05436b84e93a make/common/shared/Compiler-gcc.gmk
|--- openjdk.orig/corba/make/common/shared/Compiler-gcc.gmk	Sat Jan 16 01:04:04 2010 +0000
|+++ openjdk/corba/make/common/shared/Compiler-gcc.gmk	Thu Feb 03 16:01:37 2011 +0000
--------------------------
Patching file openjdk/corba/make/common/shared/Compiler-gcc.gmk using Plan A...
Hunk #1 succeeded at 61 with fuzz 2.
done
Checking patches/openjdk/7041156-gcc_export_dynamic.patch
Applying patches/openjdk/7041156-gcc_export_dynamic.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User dsamersoff
|# Date 1304432695 -14400
|# Node ID 250642c729b42043ea99e5e4e27d153b0c766da0
|# Parent  405c634f4aaa2e91cc87598c60a4ece6e345e5b1
|7041156: gcc 4.6 doesn't recognise -export-dynamic option
|Summary: Since -export-dynamic is a linker option, the correct way to pass it is -Xlinker -export-dynamic
|Reviewed-by: dsamersoff, dholmes
|Contributed-by: omajid at redhat.com
|
|diff -r 405c634f4aaa -r 250642c729b4 make/linux/makefiles/gcc.make
|--- openjdk/hotspot/make/linux/makefiles/gcc.make	Mon May 02 14:53:49 2011 -0700
|+++ openjdk/hotspot/make/linux/makefiles/gcc.make	Tue May 03 18:24:55 2011 +0400
--------------------------
Patching file openjdk/hotspot/make/linux/makefiles/gcc.make using Plan A...
Hunk #1 succeeded at 204 (offset -1 lines).
done
Checking patches/g344659-sparc_fix.patch
Applying patches/g344659-sparc_fix.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -uNr openjdk.orig/hotspot/src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp openjdk/hotspot/src/os_cpu/linux_sparc/vm/v_version_linux_sparc.cpp
|--- openjdk.orig/hotspot/src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp	2010-06-21 22:12:15.000000000 +0100
|+++ openjdk/hotspot/src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp	2010-11-29 20:15:36.179541001 +0000
--------------------------
Patching file openjdk/hotspot/src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp using Plan A...
Hunk #1 succeeded at 36 (offset 1 line).
done
Checking patches/openjdk/6728834-blurred-lcd-aa-text.patch
Applying patches/openjdk/6728834-blurred-lcd-aa-text.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User tdv
|# Date 1217874568 25200
|# Node ID a56641c1f54e4a81a42ca755a952fd772c14a511
|# Parent  e62bc7b05b8a7cd11d7e76f1c29cf07f0c3c7d34
|6728834: D3D/OGL: LCD AA text becomes bold and blurred when rendering to a non-opaque destination
|Reviewed-by: campbell
|
|diff -r e62bc7b05b8a -r a56641c1f54e src/share/classes/sun/java2d/opengl/OGLSurfaceData.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/opengl/OGLSurfaceData.java	Mon Aug 04 18:50:43 2008 +0400
|+++ openjdk/jdk/src/share/classes/sun/java2d/opengl/OGLSurfaceData.java	Mon Aug 04 11:29:28 2008 -0700
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/opengl/OGLSurfaceData.java using Plan A...
Hunk #1 succeeded at 401.
Hunk #2 succeeded at 411.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r e62bc7b05b8a -r a56641c1f54e src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java
|--- openjdk.orig/jdk/src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java	Mon Aug 04 18:50:43 2008 +0400
|+++ openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java	Mon Aug 04 11:29:28 2008 -0700
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java using Plan A...
Hunk #1 succeeded at 501.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r e62bc7b05b8a -r a56641c1f54e test/sun/java2d/DirectX/NonOpaqueDestLCDAATest/NonOpaqueDestLCDAATest.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/sun/java2d/DirectX/NonOpaqueDestLCDAATest/NonOpaqueDestLCDAATest.java	Mon Aug 04 11:29:28 2008 -0700
--------------------------
(Creating file openjdk/jdk/test/sun/java2d/DirectX/NonOpaqueDestLCDAATest/NonOpaqueDestLCDAATest.java...)
Patching file openjdk/jdk/test/sun/java2d/DirectX/NonOpaqueDestLCDAATest/NonOpaqueDestLCDAATest.java using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/openjdk/6749060-bad-lcd-aa-non-opaque-dest.patch
Applying patches/openjdk/6749060-bad-lcd-aa-non-opaque-dest.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User tdv
|# Date 1223597570 25200
|# Node ID 3bc4d79d8123bbc0307e0e58f7c64ee663e25af9
|# Parent  41ff3f84cd9608ef1b4ecd0a823a8ff188712784
|6749060: LCD AA text rendered incorrectly when destination is non opaque (sw pipeline only)
|Reviewed-by: campbell, prr
|
|diff -r 41ff3f84cd96 -r 3bc4d79d8123 src/share/classes/sun/java2d/SurfaceData.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/SurfaceData.java	Wed Sep 24 11:58:21 2008 -0700
|+++ openjdk/jdk/src/share/classes/sun/java2d/SurfaceData.java	Thu Oct 09 17:12:50 2008 -0700
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/SurfaceData.java using Plan A...
Hunk #1 succeeded at 449.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 41ff3f84cd96 -r 3bc4d79d8123 test/sun/java2d/DirectX/NonOpaqueDestLCDAATest/NonOpaqueDestLCDAATest.java
|--- openjdk.orig/jdk/test/sun/java2d/DirectX/NonOpaqueDestLCDAATest/NonOpaqueDestLCDAATest.java	Wed Sep 24 11:58:21 2008 -0700
|+++ openjdk/jdk/test/sun/java2d/DirectX/NonOpaqueDestLCDAATest/NonOpaqueDestLCDAATest.java	Thu Oct 09 17:12:50 2008 -0700
--------------------------
Patching file openjdk/jdk/test/sun/java2d/DirectX/NonOpaqueDestLCDAATest/NonOpaqueDestLCDAATest.java using Plan A...
Hunk #1 succeeded at 23.
Hunk #2 succeeded at 36.
Hunk #3 succeeded at 48.
Hunk #4 succeeded at 66.
Hunk #5 succeeded at 113.
Hunk #6 succeeded at 132.
Hunk #7 succeeded at 152.
done
Checking patches/openjdk/6708580-exa_slow.patch
Applying patches/openjdk/6708580-exa_slow.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User tdv
|# Date 1228418486 28800
|# Node ID 15435c60c751bc39af2fc6b3a30744c6713db1de
|# Parent  c8eea39734e85b50977434a5b37b3eb8ac8c0a59
|6708580: Java applications slow when EXA enabled
|Reviewed-by: prr, tdv
|Contributed-by: ceisserer <linuxhippy at gmail.com>
|
|diff -r c8eea39734e8 -r 15435c60c751 make/sun/awt/mapfile-mawt-vers
|--- openjdk.orig/jdk/make/sun/awt/mapfile-mawt-vers	Thu Dec 04 10:05:36 2008 -0800
|+++ openjdk/jdk/make/sun/awt/mapfile-mawt-vers	Thu Dec 04 11:21:26 2008 -0800
--------------------------
Patching file openjdk/jdk/make/sun/awt/mapfile-mawt-vers using Plan A...
Hunk #1 succeeded at 408 (offset 1 line).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r c8eea39734e8 -r 15435c60c751 make/sun/xawt/mapfile-vers
|--- openjdk.orig/jdk/make/sun/xawt/mapfile-vers	Thu Dec 04 10:05:36 2008 -0800
|+++ openjdk/jdk/make/sun/xawt/mapfile-vers	Thu Dec 04 11:21:26 2008 -0800
--------------------------
Patching file openjdk/jdk/make/sun/xawt/mapfile-vers using Plan A...
Hunk #1 succeeded at 341 (offset 4 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r c8eea39734e8 -r 15435c60c751 src/solaris/classes/sun/java2d/x11/X11SurfaceData.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/java2d/x11/X11SurfaceData.java	Thu Dec 04 10:05:36 2008 -0800
|+++ openjdk/jdk/src/solaris/classes/sun/java2d/x11/X11SurfaceData.java	Thu Dec 04 11:21:26 2008 -0800
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/java2d/x11/X11SurfaceData.java using Plan A...
Hunk #1 succeeded at 50.
Hunk #2 succeeded at 241.
Hunk #3 succeeded at 259.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r c8eea39734e8 -r 15435c60c751 src/solaris/native/sun/java2d/x11/X11SurfaceData.c
|--- openjdk.orig/jdk/src/solaris/native/sun/java2d/x11/X11SurfaceData.c	Thu Dec 04 10:05:36 2008 -0800
|+++ openjdk/jdk/src/solaris/native/sun/java2d/x11/X11SurfaceData.c	Thu Dec 04 11:21:26 2008 -0800
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/java2d/x11/X11SurfaceData.c using Plan A...
Hunk #1 succeeded at 208.
Hmm...  Ignoring the trailing garbage.
done
Checking patches/openjdk/6896068-sg2d.patch
Applying patches/openjdk/6896068-sg2d.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User neugens
|# Date 1256926775 -3600
|# Node ID 634221297c37bc73c0f598e6ce212ef83ba74d14
|# Parent  1f2ef3a7d7c023c7ffcdf4e8fbb204ec66098f80
|6896068: SunGraphics2D exposes a reference to itself while non fully initialised.
|Summary: Introduce a new Interface to mark the Loops based pipes and initialise the loops accordingly.
|Reviewed-by: flar, rkennke
|
|diff -r 1f2ef3a7d7c0 -r 634221297c37 src/share/classes/sun/java2d/SunGraphics2D.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/SunGraphics2D.java	Fri Oct 23 16:21:50 2009 +0400
|+++ openjdk/jdk/src/share/classes/sun/java2d/SunGraphics2D.java	Fri Oct 30 19:19:35 2009 +0100
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/SunGraphics2D.java using Plan A...
Hunk #1 succeeded at 256 (offset -1 lines).
Hunk #2 succeeded at 365 (offset -1 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 1f2ef3a7d7c0 -r 634221297c37 src/share/classes/sun/java2d/SurfaceData.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/SurfaceData.java	Fri Oct 23 16:21:50 2009 +0400
|+++ openjdk/jdk/src/share/classes/sun/java2d/SurfaceData.java	Fri Oct 30 19:19:35 2009 +0100
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/SurfaceData.java using Plan A...
Hunk #1 succeeded at 69.
Hunk #2 succeeded at 507.
Hunk #3 succeeded at 603.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 1f2ef3a7d7c0 -r 634221297c37 src/share/classes/sun/java2d/pipe/AATextRenderer.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pipe/AATextRenderer.java	Fri Oct 23 16:21:50 2009 +0400
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/AATextRenderer.java	Fri Oct 30 19:19:35 2009 +0100
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/AATextRenderer.java using Plan A...
Hunk #1 succeeded at 34.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 1f2ef3a7d7c0 -r 634221297c37 src/share/classes/sun/java2d/pipe/GlyphListLoopPipe.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pipe/GlyphListLoopPipe.java	Fri Oct 23 16:21:50 2009 +0400
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/GlyphListLoopPipe.java	Fri Oct 30 19:19:35 2009 +0100
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/GlyphListLoopPipe.java using Plan A...
Hunk #1 succeeded at 36.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 1f2ef3a7d7c0 -r 634221297c37 src/share/classes/sun/java2d/pipe/LoopBasedPipe.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/LoopBasedPipe.java	Fri Oct 30 19:19:35 2009 +0100
--------------------------
(Creating file openjdk/jdk/src/share/classes/sun/java2d/pipe/LoopBasedPipe.java...)
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/LoopBasedPipe.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 1f2ef3a7d7c0 -r 634221297c37 src/share/classes/sun/java2d/pipe/LoopPipe.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pipe/LoopPipe.java	Fri Oct 23 16:21:50 2009 +0400
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/LoopPipe.java	Fri Oct 30 19:19:35 2009 +0100
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/LoopPipe.java using Plan A...
Hunk #1 succeeded at 46.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 1f2ef3a7d7c0 -r 634221297c37 src/share/classes/sun/java2d/pipe/SolidTextRenderer.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pipe/SolidTextRenderer.java	Fri Oct 23 16:21:50 2009 +0400
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/SolidTextRenderer.java	Fri Oct 30 19:19:35 2009 +0100
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/SolidTextRenderer.java using Plan A...
Hunk #1 succeeded at 35.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 1f2ef3a7d7c0 -r 634221297c37 src/share/classes/sun/java2d/pipe/SpanShapeRenderer.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pipe/SpanShapeRenderer.java	Fri Oct 23 16:21:50 2009 +0400
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/SpanShapeRenderer.java	Fri Oct 30 19:19:35 2009 +0100
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/SpanShapeRenderer.java using Plan A...
Hunk #1 succeeded at 65.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 1f2ef3a7d7c0 -r 634221297c37 src/solaris/classes/sun/java2d/x11/X11SurfaceData.java
|--- openjdk.orig/jdk/src/solaris/classes/sun/java2d/x11/X11SurfaceData.java	Fri Oct 23 16:21:50 2009 +0400
|+++ openjdk/jdk/src/solaris/classes/sun/java2d/x11/X11SurfaceData.java	Fri Oct 30 19:19:35 2009 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/classes/sun/java2d/x11/X11SurfaceData.java using Plan A...
Hunk #1 succeeded at 376 (offset -12 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 1f2ef3a7d7c0 -r 634221297c37 src/windows/classes/sun/java2d/windows/GDIWindowSurfaceData.java
|--- openjdk.orig/jdk/src/windows/classes/sun/java2d/windows/GDIWindowSurfaceData.java	Fri Oct 23 16:21:50 2009 +0400
|+++ openjdk/jdk/src/windows/classes/sun/java2d/windows/GDIWindowSurfaceData.java	Fri Oct 30 19:19:35 2009 +0100
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/java2d/windows/GDIWindowSurfaceData.java using Plan A...
Hunk #1 succeeded at 212 (offset 2 lines).
done
Checking patches/openjdk/7021314-no_javaws_man_page.patch
Applying patches/openjdk/7021314-no_javaws_man_page.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User andrew
|# Date 1298481016 0
|# Node ID 5e09deee19671a6d10c7cb24ba789b5bbf6636b8
|# Parent  9b2631288894758318b59caac3b1f079fa36e98a
|7021314: Build should not install javaws man page
|Summary: Only install javaws.1 when not building OpenJDK
|Reviewed-by: alanb, ohair
|
|diff -r 9b2631288894 -r 5e09deee1967 make/common/Release.gmk
|--- openjdk/jdk/make/common/Release.gmk	Wed Feb 16 14:33:48 2011 -0800
|+++ openjdk/jdk/make/common/Release.gmk	Wed Feb 23 17:10:16 2011 +0000
--------------------------
Patching file openjdk/jdk/make/common/Release.gmk using Plan A...
Hunk #1 succeeded at 145 (offset 21 lines).
done
Checking patches/pr586-include_all_srcs.patch
Applying patches/pr586-include_all_srcs.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru openjdk.orig/jdk/make/common/Release.gmk openjdk/jdk/make/common/Release.gmk
|--- openjdk.orig/jdk/make/common/Release.gmk	2011-02-22 14:08:16.200485180 +0000
|+++ openjdk/jdk/make/common/Release.gmk	2011-02-22 14:11:03.695409585 +0000
--------------------------
Patching file openjdk/jdk/make/common/Release.gmk using Plan A...
Hunk #1 succeeded at 980 (offset 5 lines).
Hunk #2 succeeded at 988 (offset -2 lines).
done
Checking patches/jtreg-LastErrorString.patch
Applying patches/jtreg-LastErrorString.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru IOException/LastErrorString.java /home/brq/ptisnovs/IOException/LastErrorString.java
|--- openjdk-old/jdk/test/java/io/IOException/LastErrorString.java	2011-01-21 00:54:47.000000000 +0100
|+++ openjdk/jdk/test/java/io/IOException/LastErrorString.java	2011-02-21 15:34:58.972481000 +0100
--------------------------
Patching file openjdk/jdk/test/java/io/IOException/LastErrorString.java using Plan A...
Hunk #1 succeeded at 21.
Hunk #2 succeeded at 41.
Hunk #3 succeeded at 179.
Hunk #4 succeeded at 239.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -Nru IOException/LastErrorString.sh /home/brq/ptisnovs/IOException/LastErrorString.sh
|--- /dev/null	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/test/java/io/IOException/LastErrorString.sh	2011-02-21 15:34:58.972481000 +0100
--------------------------
(Creating file openjdk/jdk/test/java/io/IOException/LastErrorString.sh...)
Patching file openjdk/jdk/test/java/io/IOException/LastErrorString.sh using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/openjdk/6663040-com.sun.awt.patch
Applying patches/openjdk/6663040-com.sun.awt.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk-old/langtools/src/share/classes/com/sun/tools/javac/resources/legacy.properties	2011-01-21 00:55:18.000000000 +0100
|+++ openjdk/langtools/src/share/classes/com/sun/tools/javac/resources/legacy.properties	2011-02-22 15:28:53.010912000 +0100
--------------------------
Patching file openjdk/langtools/src/share/classes/com/sun/tools/javac/resources/legacy.properties using Plan A...
Hunk #1 succeeded at 24.
done
Checking patches/openjdk/6775317-non-AA-simple-shape-performance.patch
Applying patches/openjdk/6775317-non-AA-simple-shape-performance.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User flar
|# Date 1291700748 28800
|# Node ID 47cd69eff64122a14e1e1557bc0f6e00f66e9980
|# Parent  1d4340015b85857a7f001fff4776307f576dc274
|6775317: Improve performance of non-AA transformed rectangles and single wide lines in software pipelines
|Reviewed-by: jgodinez, prr
|
|diff -r 1d4340015b85 -r 47cd69eff641 make/sun/awt/Depend.mak
|--- openjdk.orig/jdk/make/sun/awt/Depend.mak	Mon Dec 06 16:10:01 2010 -0800
|+++ openjdk/jdk/make/sun/awt/Depend.mak	Mon Dec 06 21:45:48 2010 -0800
--------------------------
Patching file openjdk/jdk/make/sun/awt/Depend.mak using Plan A...
Hunk #1 succeeded at 18.
Hunk #2 succeeded at 65.
Hunk #3 succeeded at 73.
Hunk #4 succeeded at 147.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 1d4340015b85 -r 47cd69eff641 make/sun/awt/FILES_c_unix.gmk
|--- openjdk.orig/jdk/make/sun/awt/FILES_c_unix.gmk	Mon Dec 06 16:10:01 2010 -0800
|+++ openjdk/jdk/make/sun/awt/FILES_c_unix.gmk	Mon Dec 06 21:45:48 2010 -0800
--------------------------
Patching file openjdk/jdk/make/sun/awt/FILES_c_unix.gmk using Plan A...
Hunk #1 succeeded at 85.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 1d4340015b85 -r 47cd69eff641 make/sun/awt/FILES_c_windows.gmk
|--- openjdk.orig/jdk/make/sun/awt/FILES_c_windows.gmk	Mon Dec 06 16:10:01 2010 -0800
|+++ openjdk/jdk/make/sun/awt/FILES_c_windows.gmk	Mon Dec 06 21:45:48 2010 -0800
--------------------------
Patching file openjdk/jdk/make/sun/awt/FILES_c_windows.gmk using Plan A...
Hunk #1 succeeded at 30.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 1d4340015b85 -r 47cd69eff641 make/sun/awt/FILES_export_unix.gmk
|--- openjdk.orig/jdk/make/sun/awt/FILES_export_unix.gmk	Mon Dec 06 16:10:01 2010 -0800
|+++ openjdk/jdk/make/sun/awt/FILES_export_unix.gmk	Mon Dec 06 21:45:48 2010 -0800
--------------------------
Patching file openjdk/jdk/make/sun/awt/FILES_export_unix.gmk using Plan A...
Hunk #1 succeeded at 36.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 1d4340015b85 -r 47cd69eff641 make/sun/awt/FILES_export_windows.gmk
|--- openjdk.orig/jdk/make/sun/awt/FILES_export_windows.gmk	Mon Dec 06 16:10:01 2010 -0800
|+++ openjdk/jdk/make/sun/awt/FILES_export_windows.gmk	Mon Dec 06 21:45:48 2010 -0800
--------------------------
Patching file openjdk/jdk/make/sun/awt/FILES_export_windows.gmk using Plan A...
Hunk #1 succeeded at 134 (offset -1 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 1d4340015b85 -r 47cd69eff641 make/sun/awt/mapfile-vers
|--- openjdk.orig/jdk/make/sun/awt/mapfile-vers	Mon Dec 06 16:10:01 2010 -0800
|+++ openjdk/jdk/make/sun/awt/mapfile-vers	Mon Dec 06 21:45:48 2010 -0800
--------------------------
Patching file openjdk/jdk/make/sun/awt/mapfile-vers using Plan A...
Hunk #1 succeeded at 113 (offset 1 line).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 1d4340015b85 -r 47cd69eff641 src/share/classes/sun/java2d/SurfaceData.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/SurfaceData.java	Mon Dec 06 16:10:01 2010 -0800
|+++ openjdk/jdk/src/share/classes/sun/java2d/SurfaceData.java	Mon Dec 06 21:45:48 2010 -0800
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/SurfaceData.java using Plan A...
Hunk #1 succeeded at 46.
Hunk #2 succeeded at 63.
Hunk #3 succeeded at 369.
Hunk #4 succeeded at 402.
Hunk #5 succeeded at 437.
Hunk #6 succeeded at 475.
Hunk #7 succeeded at 489.
Hunk #8 succeeded at 546.
Hunk #9 succeeded at 572.
Hunk #10 succeeded at 584.
Hunk #11 succeeded at 666.
Hunk #12 succeeded at 691.
Hunk #13 succeeded at 849.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 1d4340015b85 -r 47cd69eff641 src/share/classes/sun/java2d/loops/DrawParallelogram.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/loops/DrawParallelogram.java	Mon Dec 06 21:45:48 2010 -0800
--------------------------
(Creating file openjdk/jdk/src/share/classes/sun/java2d/loops/DrawParallelogram.java...)
Patching file openjdk/jdk/src/share/classes/sun/java2d/loops/DrawParallelogram.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 1d4340015b85 -r 47cd69eff641 src/share/classes/sun/java2d/loops/FillParallelogram.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/loops/FillParallelogram.java	Mon Dec 06 21:45:48 2010 -0800
--------------------------
(Creating file openjdk/jdk/src/share/classes/sun/java2d/loops/FillParallelogram.java...)
Patching file openjdk/jdk/src/share/classes/sun/java2d/loops/FillParallelogram.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 1d4340015b85 -r 47cd69eff641 src/share/classes/sun/java2d/loops/RenderLoops.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/loops/RenderLoops.java	Mon Dec 06 16:10:01 2010 -0800
|+++ openjdk/jdk/src/share/classes/sun/java2d/loops/RenderLoops.java	Mon Dec 06 21:45:48 2010 -0800
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/loops/RenderLoops.java using Plan A...
Hunk #1 succeeded at 47.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 1d4340015b85 -r 47cd69eff641 src/share/classes/sun/java2d/pipe/LoopPipe.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pipe/LoopPipe.java	Mon Dec 06 16:10:01 2010 -0800
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/LoopPipe.java	Mon Dec 06 21:45:48 2010 -0800
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/LoopPipe.java using Plan A...
Hunk #1 succeeded at 41.
Hunk #2 succeeded at 350.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 1d4340015b85 -r 47cd69eff641 src/share/native/sun/java2d/loops/Any3Byte.c
|--- openjdk.orig/jdk/src/share/native/sun/java2d/loops/Any3Byte.c	Mon Dec 06 16:10:01 2010 -0800
|+++ openjdk/jdk/src/share/native/sun/java2d/loops/Any3Byte.c	Mon Dec 06 21:45:48 2010 -0800
--------------------------
Patching file openjdk/jdk/src/share/native/sun/java2d/loops/Any3Byte.c using Plan A...
Hunk #1 succeeded at 38.
Hunk #2 succeeded at 49.
Hunk #3 succeeded at 74.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 1d4340015b85 -r 47cd69eff641 src/share/native/sun/java2d/loops/Any4Byte.c
|--- openjdk.orig/jdk/src/share/native/sun/java2d/loops/Any4Byte.c	Mon Dec 06 16:10:01 2010 -0800
|+++ openjdk/jdk/src/share/native/sun/java2d/loops/Any4Byte.c	Mon Dec 06 21:45:48 2010 -0800
--------------------------
Patching file openjdk/jdk/src/share/native/sun/java2d/loops/Any4Byte.c using Plan A...
Hunk #1 succeeded at 41.
Hunk #2 succeeded at 52.
Hunk #3 succeeded at 77.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 1d4340015b85 -r 47cd69eff641 src/share/native/sun/java2d/loops/AnyByte.c
|--- openjdk.orig/jdk/src/share/native/sun/java2d/loops/AnyByte.c	Mon Dec 06 16:10:01 2010 -0800
|+++ openjdk/jdk/src/share/native/sun/java2d/loops/AnyByte.c	Mon Dec 06 21:45:48 2010 -0800
--------------------------
Patching file openjdk/jdk/src/share/native/sun/java2d/loops/AnyByte.c using Plan A...
Hunk #1 succeeded at 38.
Hunk #2 succeeded at 49.
Hunk #3 succeeded at 74.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 1d4340015b85 -r 47cd69eff641 src/share/native/sun/java2d/loops/AnyInt.c
|--- openjdk.orig/jdk/src/share/native/sun/java2d/loops/AnyInt.c	Mon Dec 06 16:10:01 2010 -0800
|+++ openjdk/jdk/src/share/native/sun/java2d/loops/AnyInt.c	Mon Dec 06 21:45:48 2010 -0800
--------------------------
Patching file openjdk/jdk/src/share/native/sun/java2d/loops/AnyInt.c using Plan A...
Hunk #1 succeeded at 38.
Hunk #2 succeeded at 49.
Hunk #3 succeeded at 74.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 1d4340015b85 -r 47cd69eff641 src/share/native/sun/java2d/loops/AnyShort.c
|--- openjdk.orig/jdk/src/share/native/sun/java2d/loops/AnyShort.c	Mon Dec 06 16:10:01 2010 -0800
|+++ openjdk/jdk/src/share/native/sun/java2d/loops/AnyShort.c	Mon Dec 06 21:45:48 2010 -0800
--------------------------
Patching file openjdk/jdk/src/share/native/sun/java2d/loops/AnyShort.c using Plan A...
Hunk #1 succeeded at 38.
Hunk #2 succeeded at 49.
Hunk #3 succeeded at 74.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 1d4340015b85 -r 47cd69eff641 src/share/native/sun/java2d/loops/DrawParallelogram.c
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/share/native/sun/java2d/loops/DrawParallelogram.c	Mon Dec 06 21:45:48 2010 -0800
--------------------------
(Creating file openjdk/jdk/src/share/native/sun/java2d/loops/DrawParallelogram.c...)
Patching file openjdk/jdk/src/share/native/sun/java2d/loops/DrawParallelogram.c using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 1d4340015b85 -r 47cd69eff641 src/share/native/sun/java2d/loops/FillParallelogram.c
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/share/native/sun/java2d/loops/FillParallelogram.c	Mon Dec 06 21:45:48 2010 -0800
--------------------------
(Creating file openjdk/jdk/src/share/native/sun/java2d/loops/FillParallelogram.c...)
Patching file openjdk/jdk/src/share/native/sun/java2d/loops/FillParallelogram.c using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 1d4340015b85 -r 47cd69eff641 src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.c
|--- openjdk.orig/jdk/src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.c	Mon Dec 06 16:10:01 2010 -0800
|+++ openjdk/jdk/src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.c	Mon Dec 06 21:45:48 2010 -0800
--------------------------
Patching file openjdk/jdk/src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.c using Plan A...
Hunk #1 succeeded at 574.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 1d4340015b85 -r 47cd69eff641 src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.h
|--- openjdk.orig/jdk/src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.h	Mon Dec 06 16:10:01 2010 -0800
|+++ openjdk/jdk/src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.h	Mon Dec 06 21:45:48 2010 -0800
--------------------------
Patching file openjdk/jdk/src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.h using Plan A...
Hunk #1 succeeded at 334.
Hunk #2 succeeded at 383.
Hunk #3 succeeded at 415.
Hunk #4 succeeded at 560.
Hunk #5 succeeded at 620.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 1d4340015b85 -r 47cd69eff641 src/share/native/sun/java2d/loops/LoopMacros.h
|--- openjdk.orig/jdk/src/share/native/sun/java2d/loops/LoopMacros.h	Mon Dec 06 16:10:01 2010 -0800
|+++ openjdk/jdk/src/share/native/sun/java2d/loops/LoopMacros.h	Mon Dec 06 21:45:48 2010 -0800
--------------------------
Patching file openjdk/jdk/src/share/native/sun/java2d/loops/LoopMacros.h using Plan A...
Hunk #1 succeeded at 607.
Hunk #2 succeeded at 695.
Hunk #3 succeeded at 816.
Hunk #4 succeeded at 1293.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 1d4340015b85 -r 47cd69eff641 src/solaris/native/sun/java2d/loops/java2d_Mlib.c
|--- openjdk.orig/jdk/src/solaris/native/sun/java2d/loops/java2d_Mlib.c	Mon Dec 06 16:10:01 2010 -0800
|+++ openjdk/jdk/src/solaris/native/sun/java2d/loops/java2d_Mlib.c	Mon Dec 06 21:45:48 2010 -0800
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/java2d/loops/java2d_Mlib.c using Plan A...
Hunk #1 succeeded at 282.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 1d4340015b85 -r 47cd69eff641 src/solaris/native/sun/java2d/loops/vis_FuncArray.c
|--- openjdk.orig/jdk/src/solaris/native/sun/java2d/loops/vis_FuncArray.c	Mon Dec 06 16:10:01 2010 -0800
|+++ openjdk/jdk/src/solaris/native/sun/java2d/loops/vis_FuncArray.c	Mon Dec 06 21:45:48 2010 -0800
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/java2d/loops/vis_FuncArray.c using Plan A...
Hunk #1 succeeded at 51.
Hunk #2 succeeded at 63.
Hunk #3 succeeded at 75.
Hunk #4 succeeded at 87.
Hunk #5 succeeded at 99.
Hunk #6 succeeded at 518.
Hunk #7 succeeded at 530.
Hunk #8 succeeded at 540.
Hunk #9 succeeded at 552.
Hunk #10 succeeded at 564.
done
Checking patches/pr600-arm-jvm.cfg.patch
Applying patches/pr600-arm-jvm.cfg.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: openjdk/jdk/src/solaris/bin/arm/jvm.cfg
|===================================================================
|--- /dev/null	1970-01-01 00:00:00.000000000 +0000
|+++ openjdk/jdk/src/solaris/bin/arm/jvm.cfg	2011-02-18 15:40:24.083043645 +0100
--------------------------
(Creating file openjdk/jdk/src/solaris/bin/arm/jvm.cfg...)
Patching file openjdk/jdk/src/solaris/bin/arm/jvm.cfg using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/openjdk/6887494-NPE-in-pisces.patch
Applying patches/openjdk/6887494-NPE-in-pisces.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User rkennke
|# Date 1254777142 -7200
|# Node ID ccc36189f2a7615ffb798e76ba5b31d8c535dc40
|# Parent  31e68419715e0a8e88ee6005ab1d69180cfe6f44
|6887494: NPE in pisces Renderer
|Summary: Only recreate crossings array, if there actually exists one before.
|Reviewed-by: flar, tdv
|
|diff -r 31e68419715e -r ccc36189f2a7 src/share/classes/sun/java2d/pisces/Renderer.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pisces/Renderer.java	Fri Oct 02 10:15:12 2009 -0700
|+++ openjdk/jdk/src/share/classes/sun/java2d/pisces/Renderer.java	Mon Oct 05 23:12:22 2009 +0200
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/Renderer.java using Plan A...
Hunk #1 succeeded at 775.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 31e68419715e -r ccc36189f2a7 test/sun/java2d/pisces/Renderer/TestNPE.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/sun/java2d/pisces/Renderer/TestNPE.java	Mon Oct 05 23:12:22 2009 +0200
--------------------------
(Creating file openjdk/jdk/test/sun/java2d/pisces/Renderer/TestNPE.java...)
Patching file openjdk/jdk/test/sun/java2d/pisces/Renderer/TestNPE.java using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/openjdk/6967436-6967433-floating-pt-conversion.patch
Applying patches/openjdk/6967436-6967433-floating-pt-conversion.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/jdk/make/sun/pisces/Makefile.orig  2011-02-23 20:16:27.116261331 -0500
|+++ openjdk/jdk/make/sun/pisces/Makefile   2011-02-23 20:17:08.106141482 -0500
--------------------------
Patching file openjdk/jdk/make/sun/pisces/Makefile using Plan A...
Hunk #1 succeeded at 28.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r cf0c23a99823 -r d47bd9d94ba4 src/share/classes/sun/java2d/pisces/Dasher.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pisces/Dasher.java	Thu Jul 29 17:12:27 2010 -0700
|+++ openjdk/jdk/src/share/classes/sun/java2d/pisces/Dasher.java	Tue Aug 10 13:19:44 2010 -0400
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/Dasher.java using Plan A...
Hunk #1 succeeded at 36.
Hunk #2 succeeded at 114.
Hunk #3 succeeded at 134.
Hunk #4 succeeded at 199.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r cf0c23a99823 -r d47bd9d94ba4 src/share/classes/sun/java2d/pisces/LineSink.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pisces/LineSink.java	Thu Jul 29 17:12:27 2010 -0700
|+++ openjdk/jdk/src/share/classes/sun/java2d/pisces/LineSink.java	Tue Aug 10 13:19:44 2010 -0400
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/LineSink.java using Plan A...
Hunk #1 succeeded at 39.
Hunk #2 succeeded at 65.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -N -r cf0c23a99823 -r d47bd9d94ba4 src/share/classes/sun/java2d/pisces/PiscesMath.java
|--- openjdk/jdk/src/share/classes/sun/java2d/pisces/PiscesMath.java	Thu Jul 29 17:12:27 2010 -0700
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/PiscesMath.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r cf0c23a99823 -r d47bd9d94ba4 src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java	Thu Jul 29 17:12:27 2010 -0700
|+++ openjdk/jdk/src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java	Tue Aug 10 13:19:44 2010 -0400
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java using Plan A...
Hunk #1 succeeded at 37.
Hunk #2 succeeded at 69.
Hunk #3 succeeded at 129.
Hunk #4 succeeded at 166.
Hunk #5 succeeded at 244.
Hunk #6 succeeded at 252.
Hunk #7 succeeded at 273.
Hunk #8 succeeded at 347.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r cf0c23a99823 -r d47bd9d94ba4 src/share/classes/sun/java2d/pisces/Renderer.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pisces/Renderer.java	Thu Jul 29 17:12:27 2010 -0700
|+++ openjdk/jdk/src/share/classes/sun/java2d/pisces/Renderer.java	Tue Aug 10 13:19:44 2010 -0400
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/Renderer.java using Plan A...
Hunk #1 succeeded at 25.
Hunk #2 succeeded at 472.
Hunk #3 succeeded at 505.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r cf0c23a99823 -r d47bd9d94ba4 src/share/classes/sun/java2d/pisces/Stroker.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pisces/Stroker.java	Thu Jul 29 17:12:27 2010 -0700
|+++ openjdk/jdk/src/share/classes/sun/java2d/pisces/Stroker.java	Tue Aug 10 13:19:44 2010 -0400
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/Stroker.java using Plan A...
Hunk #1 succeeded at 25.
Hunk #2 succeeded at 61.
Hunk #3 succeeded at 84.
Hunk #4 succeeded at 172.
Hunk #5 succeeded at 205.
Hunk #6 succeeded at 261.
Hunk #7 succeeded at 285.
Hunk #8 succeeded at 315.
Hunk #9 succeeded at 330.
Hunk #10 succeeded at 377.
Hunk #11 succeeded at 389.
Hunk #12 succeeded at 417.
Hunk #13 succeeded at 442.
Hunk #14 succeeded at 483.
Hunk #15 succeeded at 506.
Hunk #16 succeeded at 590.
Hunk #17 succeeded at 602.
Hunk #18 succeeded at 624.
Hunk #19 succeeded at 640.
Hunk #20 succeeded at 665.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r cf0c23a99823 -r d47bd9d94ba4 src/share/classes/sun/java2d/pisces/Transform4.java
|--- openjdk/jdk/src/share/classes/sun/java2d/pisces/Transform4.java	Thu Jul 29 17:12:27 2010 -0700
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/Transform4.java using Plan A...
Hunk #1 succeeded at 0.
done
Checking patches/openjdk/6976265-stroke-control.patch
Applying patches/openjdk/6976265-stroke-control.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User dlila
|# Date 1281535556 14400
|# Node ID 4285edea9ddbd85374826342d8b4d829a76f49ca
|# Parent  d47bd9d94ba42529aa1adb6d521ebea8fcc00031
|6976265: No STROKE_CONTROL
|Summary: implemented it in sun.java2d.pisces by adding a PathIterator.
|Reviewed-by: flar
|
|diff -r d47bd9d94ba4 -r 4285edea9ddb src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java	Tue Aug 10 13:19:44 2010 -0400
|+++ openjdk/jdk/src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java	Wed Aug 11 10:05:56 2010 -0400
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java using Plan A...
Hunk #1 succeeded at 27.
Hunk #2 succeeded at 40.
Hunk #3 succeeded at 72.
Hunk #4 succeeded at 130.
Hunk #5 succeeded at 155.
Hunk #6 succeeded at 250.
Hunk #7 succeeded at 269.
Hunk #8 succeeded at 473.
Hunk #9 succeeded at 493.
Hunk #10 succeeded at 524.
done
Checking patches/openjdk/6967434-bad-round-joins.patch
Applying patches/openjdk/6967434-bad-round-joins.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User dlila
|# Date 1288103963 14400
|# Node ID 065e6c5a80276390345fe863724e8207e43c7b08
|# Parent  12b65e7ee3e41c8f6ba49b86dfb347dd38d84e09
|6967434: Round joins/caps of scaled up lines have poor quality.
|Summary: eliminated flattening from the rendering engine.
|Reviewed-by: flar
|
|diff -r 12b65e7ee3e4 -r 065e6c5a8027 src/share/classes/sun/java2d/pisces/Curve.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/pisces/Curve.java	Tue Oct 26 10:39:23 2010 -0400
--------------------------
(Creating file openjdk/jdk/src/share/classes/sun/java2d/pisces/Curve.java...)
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/Curve.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 12b65e7ee3e4 -r 065e6c5a8027 src/share/classes/sun/java2d/pisces/Dasher.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pisces/Dasher.java	Fri Oct 22 16:57:41 2010 +0400
|+++ openjdk/jdk/src/share/classes/sun/java2d/pisces/Dasher.java	Tue Oct 26 10:39:23 2010 -0400
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/Dasher.java using Plan A...
Hunk #1 succeeded at 25.
Hunk #2 succeeded at 38.
Hunk #3 succeeded at 55.
Hunk #4 succeeded at 87.
Hunk #5 succeeded at 108.
Hunk #6 succeeded at 217.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 12b65e7ee3e4 -r 065e6c5a8027 src/share/classes/sun/java2d/pisces/Helpers.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/pisces/Helpers.java	Tue Oct 26 10:39:23 2010 -0400
--------------------------
(Creating file openjdk/jdk/src/share/classes/sun/java2d/pisces/Helpers.java...)
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/Helpers.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 12b65e7ee3e4 -r 065e6c5a8027 src/share/classes/sun/java2d/pisces/LineSink.java
|--- openjdk/jdk/src/share/classes/sun/java2d/pisces/LineSink.java	Fri Oct 22 16:57:41 2010 +0400
|+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/LineSink.java using Plan A...
Hunk #1 succeeded at 0.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 12b65e7ee3e4 -r 065e6c5a8027 src/share/classes/sun/java2d/pisces/PiscesCache.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pisces/PiscesCache.java	Fri Oct 22 16:57:41 2010 +0400
|+++ openjdk/jdk/src/share/classes/sun/java2d/pisces/PiscesCache.java	Tue Oct 26 10:39:23 2010 -0400
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/PiscesCache.java using Plan A...
Hunk #1 succeeded at 25.
Hunk #2 succeeded at 34.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 12b65e7ee3e4 -r 065e6c5a8027 src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java	Fri Oct 22 16:57:41 2010 +0400
|+++ openjdk/jdk/src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java	Tue Oct 26 10:39:23 2010 -0400
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java using Plan A...
Hunk #1 succeeded at 27.
Hunk #2 succeeded at 38.
Hunk #3 succeeded at 76.
Hunk #4 succeeded at 140.
Hunk #5 succeeded at 149.
Hunk #6 succeeded at 170.
Hunk #7 succeeded at 248.
Hunk #8 succeeded at 414.
Hunk #9 succeeded at 470.
Hunk #10 succeeded at 530.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 12b65e7ee3e4 -r 065e6c5a8027 src/share/classes/sun/java2d/pisces/PiscesTileGenerator.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pisces/PiscesTileGenerator.java	Fri Oct 22 16:57:41 2010 +0400
|+++ openjdk/jdk/src/share/classes/sun/java2d/pisces/PiscesTileGenerator.java	Tue Oct 26 10:39:23 2010 -0400
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/PiscesTileGenerator.java using Plan A...
Hunk #1 succeeded at 25.
Hunk #2 succeeded at 110.
Hunk #3 succeeded at 164.
Hunk #4 succeeded at 189.
Hunk #5 succeeded at 213.
Hunk #6 succeeded at 250.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 12b65e7ee3e4 -r 065e6c5a8027 src/share/classes/sun/java2d/pisces/Renderer.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pisces/Renderer.java	Fri Oct 22 16:57:41 2010 +0400
|+++ openjdk/jdk/src/share/classes/sun/java2d/pisces/Renderer.java	Tue Oct 26 10:39:23 2010 -0400
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/Renderer.java using Plan A...
Hunk #1 succeeded at 26.
Hunk #2 succeeded at 586.
Hunk #3 succeeded at 603.
Hunk #4 succeeded at 613.
Hunk #5 succeeded at 629.
Hunk #6 succeeded at 638.
Hunk #7 succeeded at 745.
Hunk #8 succeeded at 794.
Hunk #9 succeeded at 808.
Hunk #10 succeeded at 863.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 12b65e7ee3e4 -r 065e6c5a8027 src/share/classes/sun/java2d/pisces/Stroker.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pisces/Stroker.java	Fri Oct 22 16:57:41 2010 +0400
|+++ openjdk/jdk/src/share/classes/sun/java2d/pisces/Stroker.java	Tue Oct 26 10:39:23 2010 -0400
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/Stroker.java using Plan A...
Hunk #1 succeeded at 25.
Hunk #2 succeeded at 69.
Hunk #3 succeeded at 108.
Hunk #4 succeeded at 180.
Hunk #5 succeeded at 332.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 12b65e7ee3e4 -r 065e6c5a8027 src/share/classes/sun/java2d/pisces/TransformingPathConsumer2D.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/share/classes/sun/java2d/pisces/TransformingPathConsumer2D.java	Tue Oct 26 10:39:23 2010 -0400
--------------------------
(Creating file openjdk/jdk/src/share/classes/sun/java2d/pisces/TransformingPathConsumer2D.java...)
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/TransformingPathConsumer2D.java using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/openjdk/6766342-AA-simple-shape-performance.patch
Applying patches/openjdk/6766342-AA-simple-shape-performance.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User flar
|# Date 1292361929 28800
|# Node ID 4d6f9aaa2600eec36725ab7cd47cb4b652755723
|# Parent  0eeac8ca33e329aab7a9ad0fcfb3a321cd1abd06
|6766342: Improve performance of Ductus rasterizer
|Reviewed-by: jgodinez, prr
|
|diff -r 0eeac8ca33e3 -r 4d6f9aaa2600 make/sun/awt/mapfile-vers
|--- openjdk.orig/jdk/make/sun/awt/mapfile-vers	Fri Dec 10 16:14:04 2010 -0800
|+++ openjdk/jdk/make/sun/awt/mapfile-vers	Tue Dec 14 13:25:29 2010 -0800
--------------------------
Patching file openjdk/jdk/make/sun/awt/mapfile-vers using Plan A...
Hunk #1 succeeded at 119 (offset 1 line).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 0eeac8ca33e3 -r 4d6f9aaa2600 make/sun/awt/mapfile-vers-linux
|--- openjdk.orig/jdk/make/sun/awt/mapfile-vers-linux	Fri Dec 10 16:14:04 2010 -0800
|+++ openjdk/jdk/make/sun/awt/mapfile-vers-linux	Tue Dec 14 13:25:29 2010 -0800
--------------------------
Patching file openjdk/jdk/make/sun/awt/mapfile-vers-linux using Plan A...
Hunk #1 succeeded at 115 with fuzz 2.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 0eeac8ca33e3 -r 4d6f9aaa2600 src/share/classes/sun/dc/DuctusRenderingEngine.java
|--- openjdk.orig/jdk/src/share/classes/sun/dc/DuctusRenderingEngine.java	Fri Dec 10 16:14:04 2010 -0800
|+++ openjdk/jdk/src/share/classes/sun/dc/DuctusRenderingEngine.java	Tue Dec 14 13:25:29 2010 -0800
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/dc/DuctusRenderingEngine.java using Plan A...
Hunk #1 succeeded at 635.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 0eeac8ca33e3 -r 4d6f9aaa2600 src/share/classes/sun/java2d/SurfaceData.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/SurfaceData.java	Fri Dec 10 16:14:04 2010 -0800
|+++ openjdk/jdk/src/share/classes/sun/java2d/SurfaceData.java	Tue Dec 14 13:25:29 2010 -0800
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/SurfaceData.java using Plan A...
Hunk #1 succeeded at 367.
Hunk #2 succeeded at 386.
Hunk #3 succeeded at 397.
Hunk #4 succeeded at 428.
Hunk #5 succeeded at 462.
Hunk #6 succeeded at 474.
Hunk #7 succeeded at 485.
Hunk #8 succeeded at 609.
Hunk #9 succeeded at 634.
Hunk #10 succeeded at 656.
Hunk #11 succeeded at 815.
Hunk #12 succeeded at 836.
Hunk #13 succeeded at 851.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 0eeac8ca33e3 -r 4d6f9aaa2600 src/share/classes/sun/java2d/loops/CompositeType.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/loops/CompositeType.java	Fri Dec 10 16:14:04 2010 -0800
|+++ openjdk/jdk/src/share/classes/sun/java2d/loops/CompositeType.java	Tue Dec 14 13:25:29 2010 -0800
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/loops/CompositeType.java using Plan A...
Hunk #1 succeeded at 27.
Hunk #2 succeeded at 52.
Hunk #3 succeeded at 159.
Hunk #4 succeeded at 232.
Hunk #5 succeeded at 239.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 0eeac8ca33e3 -r 4d6f9aaa2600 src/share/classes/sun/java2d/loops/MaskFill.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/loops/MaskFill.java	Fri Dec 10 16:14:04 2010 -0800
|+++ openjdk/jdk/src/share/classes/sun/java2d/loops/MaskFill.java	Tue Dec 14 13:25:29 2010 -0800
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/loops/MaskFill.java using Plan A...
Hunk #1 succeeded at 50.
Hunk #2 succeeded at 96.
Hunk #3 succeeded at 127.
Hunk #4 succeeded at 211.
Hunk #5 succeeded at 242.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 0eeac8ca33e3 -r 4d6f9aaa2600 src/share/classes/sun/java2d/pipe/AAShapePipe.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pipe/AAShapePipe.java	Fri Dec 10 16:14:04 2010 -0800
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/AAShapePipe.java	Tue Dec 14 13:25:29 2010 -0800
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/AAShapePipe.java using Plan A...
Hunk #1 succeeded at 28.
Hunk #2 succeeded at 40.
Hunk #3 succeeded at 68.
Hunk #4 succeeded at 141.
Hunk #5 succeeded at 152.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 0eeac8ca33e3 -r 4d6f9aaa2600 src/share/classes/sun/java2d/pipe/AlphaColorPipe.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pipe/AlphaColorPipe.java	Fri Dec 10 16:14:04 2010 -0800
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/AlphaColorPipe.java	Tue Dec 14 13:25:29 2010 -0800
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/AlphaColorPipe.java using Plan A...
Hunk #1 succeeded at 34.
Hunk #2 succeeded at 64.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 0eeac8ca33e3 -r 4d6f9aaa2600 src/share/classes/sun/java2d/pipe/RenderingEngine.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pipe/RenderingEngine.java	Fri Dec 10 16:14:04 2010 -0800
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/RenderingEngine.java	Tue Dec 14 13:25:29 2010 -0800
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/RenderingEngine.java using Plan A...
Hunk #1 succeeded at 264 (offset -17 lines).
Hunk #2 succeeded at 442 (offset -17 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 0eeac8ca33e3 -r 4d6f9aaa2600 src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java	Fri Dec 10 16:14:04 2010 -0800
|+++ openjdk/jdk/src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java	Tue Dec 14 13:25:29 2010 -0800
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java using Plan A...
Hunk #1 succeeded at 557.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 0eeac8ca33e3 -r 4d6f9aaa2600 src/share/native/sun/java2d/loops/DrawParallelogram.c
|--- openjdk.orig/jdk/src/share/native/sun/java2d/loops/DrawParallelogram.c	Fri Dec 10 16:14:04 2010 -0800
|+++ openjdk/jdk/src/share/native/sun/java2d/loops/DrawParallelogram.c	Tue Dec 14 13:25:29 2010 -0800
--------------------------
Patching file openjdk/jdk/src/share/native/sun/java2d/loops/DrawParallelogram.c using Plan A...
Hunk #1 succeeded at 26.
Hunk #2 succeeded at 43.
Hunk #3 succeeded at 111.
Hunk #4 succeeded at 124.
Hunk #5 succeeded at 175.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 0eeac8ca33e3 -r 4d6f9aaa2600 src/share/native/sun/java2d/loops/FillParallelogram.c
|--- openjdk.orig/jdk/src/share/native/sun/java2d/loops/FillParallelogram.c	Fri Dec 10 16:14:04 2010 -0800
|+++ openjdk/jdk/src/share/native/sun/java2d/loops/FillParallelogram.c	Tue Dec 14 13:25:29 2010 -0800
--------------------------
Patching file openjdk/jdk/src/share/native/sun/java2d/loops/FillParallelogram.c using Plan A...
Hunk #1 succeeded at 25.
Hunk #2 succeeded at 55.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 0eeac8ca33e3 -r 4d6f9aaa2600 src/share/native/sun/java2d/loops/MaskFill.c
|--- openjdk.orig/jdk/src/share/native/sun/java2d/loops/MaskFill.c	Fri Dec 10 16:14:04 2010 -0800
|+++ openjdk/jdk/src/share/native/sun/java2d/loops/MaskFill.c	Tue Dec 14 13:25:29 2010 -0800
--------------------------
Patching file openjdk/jdk/src/share/native/sun/java2d/loops/MaskFill.c using Plan A...
Hunk #1 succeeded at 23.
Hunk #2 succeeded at 97.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 0eeac8ca33e3 -r 4d6f9aaa2600 src/share/native/sun/java2d/loops/ParallelogramUtils.h
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/src/share/native/sun/java2d/loops/ParallelogramUtils.h	Tue Dec 14 13:25:29 2010 -0800
--------------------------
(Creating file openjdk/jdk/src/share/native/sun/java2d/loops/ParallelogramUtils.h...)
Patching file openjdk/jdk/src/share/native/sun/java2d/loops/ParallelogramUtils.h using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 0eeac8ca33e3 -r 4d6f9aaa2600 src/solaris/native/sun/java2d/loops/vis_IntArgbPre_Mask.c
|--- openjdk.orig/jdk/src/solaris/native/sun/java2d/loops/vis_IntArgbPre_Mask.c	Fri Dec 10 16:14:04 2010 -0800
|+++ openjdk/jdk/src/solaris/native/sun/java2d/loops/vis_IntArgbPre_Mask.c	Tue Dec 14 13:25:29 2010 -0800
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/java2d/loops/vis_IntArgbPre_Mask.c using Plan A...
Hunk #1 succeeded at 517.
Hunk #2 succeeded at 584.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 0eeac8ca33e3 -r 4d6f9aaa2600 src/solaris/native/sun/java2d/loops/vis_SrcMaskFill.c
|--- openjdk.orig/jdk/src/solaris/native/sun/java2d/loops/vis_SrcMaskFill.c	Fri Dec 10 16:14:04 2010 -0800
|+++ openjdk/jdk/src/solaris/native/sun/java2d/loops/vis_SrcMaskFill.c	Tue Dec 14 13:25:29 2010 -0800
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/java2d/loops/vis_SrcMaskFill.c using Plan A...
Hunk #1 succeeded at 150.
Hunk #2 succeeded at 216.
Hunk #3 succeeded at 394.
Hunk #4 succeeded at 464.
Hunk #5 succeeded at 534.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 0eeac8ca33e3 -r 4d6f9aaa2600 test/java/awt/Graphics2D/RenderClipTest/6766342.tests
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/java/awt/Graphics2D/RenderClipTest/6766342.tests	Tue Dec 14 13:25:29 2010 -0800
--------------------------
(Creating file openjdk/jdk/test/java/awt/Graphics2D/RenderClipTest/6766342.tests...)
Patching file openjdk/jdk/test/java/awt/Graphics2D/RenderClipTest/6766342.tests using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 0eeac8ca33e3 -r 4d6f9aaa2600 test/java/awt/Graphics2D/RenderClipTest/RenderClipTest.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/java/awt/Graphics2D/RenderClipTest/RenderClipTest.java	Tue Dec 14 13:25:29 2010 -0800
--------------------------
(Creating file openjdk/jdk/test/java/awt/Graphics2D/RenderClipTest/RenderClipTest.java...)
Patching file openjdk/jdk/test/java/awt/Graphics2D/RenderClipTest/RenderClipTest.java using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/openjdk/7016856-pisces-performance.patch
Applying patches/openjdk/7016856-pisces-performance.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User dlila
|# Date 1297174969 18000
|# Node ID 5e624003e6225ec1ee92536bc356cba90043826c
|# Parent  21621a756b32028fde37935cd91330a8e194f96b
|7016856: dashing performance was reduced during latest changes to the OpenJDK rasterizer
|Summary: Optimized dashing, rasterizing, and the flow of transformed coordinates
|Reviewed-by: flar
|
|diff -r 21621a756b32 -r 5e624003e622 src/share/classes/sun/java2d/pisces/Curve.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pisces/Curve.java	Thu Feb 03 19:15:30 2011 -0800
|+++ openjdk/jdk/src/share/classes/sun/java2d/pisces/Curve.java	Tue Feb 08 09:22:49 2011 -0500
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/Curve.java using Plan A...
Hunk #1 succeeded at 27.
Hunk #2 succeeded at 101.
Hunk #3 succeeded at 123.
Hunk #4 succeeded at 153.
Hunk #5 succeeded at 181.
Hunk #6 succeeded at 196.
Hunk #7 succeeded at 219.
Hunk #8 succeeded at 286.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 21621a756b32 -r 5e624003e622 src/share/classes/sun/java2d/pisces/Dasher.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pisces/Dasher.java	Thu Feb 03 19:15:30 2011 -0800
|+++ openjdk/jdk/src/share/classes/sun/java2d/pisces/Dasher.java	Tue Feb 08 09:22:49 2011 -0500
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/Dasher.java using Plan A...
Hunk #1 succeeded at 38.
Hunk #2 succeeded at 169.
Hunk #3 succeeded at 226.
Hunk #4 succeeded at 237.
Hunk #5 succeeded at 307.
Hunk #6 succeeded at 349.
Hunk #7 succeeded at 403.
Hunk #8 succeeded at 463.
Hunk #9 succeeded at 491.
Hunk #10 succeeded at 507.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 21621a756b32 -r 5e624003e622 src/share/classes/sun/java2d/pisces/Helpers.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pisces/Helpers.java	Thu Feb 03 19:15:30 2011 -0800
|+++ openjdk/jdk/src/share/classes/sun/java2d/pisces/Helpers.java	Tue Feb 08 09:22:49 2011 -0500
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/Helpers.java using Plan A...
Hunk #1 succeeded at 26.
Hunk #2 succeeded at 81.
Hunk #3 succeeded at 162.
Hunk #4 succeeded at 189.
Hunk #5 succeeded at 206.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 21621a756b32 -r 5e624003e622 src/share/classes/sun/java2d/pisces/PiscesCache.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pisces/PiscesCache.java	Thu Feb 03 19:15:30 2011 -0800
|+++ openjdk/jdk/src/share/classes/sun/java2d/pisces/PiscesCache.java	Tue Feb 08 09:22:49 2011 -0500
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/PiscesCache.java using Plan A...
Hunk #1 succeeded at 32.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 21621a756b32 -r 5e624003e622 src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java	Thu Feb 03 19:15:30 2011 -0800
|+++ openjdk/jdk/src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java	Tue Feb 08 09:22:49 2011 -0500
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java using Plan A...
Hunk #1 succeeded at 27.
Hunk #2 succeeded at 249.
Hunk #3 succeeded at 264.
Hunk #4 succeeded at 283.
Hunk #5 succeeded at 312.
Hunk #6 succeeded at 349.
Hunk #7 succeeded at 598.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 21621a756b32 -r 5e624003e622 src/share/classes/sun/java2d/pisces/PiscesTileGenerator.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pisces/PiscesTileGenerator.java	Thu Feb 03 19:15:30 2011 -0800
|+++ openjdk/jdk/src/share/classes/sun/java2d/pisces/PiscesTileGenerator.java	Tue Feb 08 09:22:49 2011 -0500
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/PiscesTileGenerator.java using Plan A...
Hunk #1 succeeded at 30.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 21621a756b32 -r 5e624003e622 src/share/classes/sun/java2d/pisces/Renderer.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pisces/Renderer.java	Thu Feb 03 19:15:30 2011 -0800
|+++ openjdk/jdk/src/share/classes/sun/java2d/pisces/Renderer.java	Tue Feb 08 09:22:49 2011 -0500
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/Renderer.java using Plan A...
Hunk #1 succeeded at 25.
Hunk #2 succeeded at 36.
Hunk #3 succeeded at 120.
Hunk #4 succeeded at 128.
Hunk #5 succeeded at 219.
Hunk #6 succeeded at 365.
Hunk #7 succeeded at 386.
Hunk #8 succeeded at 438.
Hunk #9 succeeded at 476.
Hunk #10 succeeded at 522.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 21621a756b32 -r 5e624003e622 src/share/classes/sun/java2d/pisces/Stroker.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pisces/Stroker.java	Thu Feb 03 19:15:30 2011 -0800
|+++ openjdk/jdk/src/share/classes/sun/java2d/pisces/Stroker.java	Tue Feb 08 09:22:49 2011 -0500
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/Stroker.java using Plan A...
Hunk #1 succeeded at 33.
Hunk #2 succeeded at 130.
Hunk #3 succeeded at 758.
Hunk #4 succeeded at 766.
Hunk #5 succeeded at 822.
Hunk #6 succeeded at 871.
Hunk #7 succeeded at 918.
Hunk #8 succeeded at 928.
Hunk #9 succeeded at 940.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 21621a756b32 -r 5e624003e622 src/share/classes/sun/java2d/pisces/TransformingPathConsumer2D.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pisces/TransformingPathConsumer2D.java	Thu Feb 03 19:15:30 2011 -0800
|+++ openjdk/jdk/src/share/classes/sun/java2d/pisces/TransformingPathConsumer2D.java	Tue Feb 08 09:22:49 2011 -0500
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/TransformingPathConsumer2D.java using Plan A...
Hunk #1 succeeded at 28.
Hunk #2 succeeded at 50.
Hunk #3 succeeded at 162.
Hunk #4 succeeded at 216.
Hunk #5 succeeded at 281.
done
Checking patches/openjdk/6934977-MappedByteBuffer.load.patch
Applying patches/openjdk/6934977-MappedByteBuffer.load.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User alanb
|# Date 1280405338 -3600
|# Node ID 24741c4bf300b4bfffdcfe92c747558d20842082
|# Parent  5ff8b884a92c0294ab60e20b00b83274eca3170e
|6934977: (bf) MappedByteBuffer.load can SIGBUS if file is truncated
|6799037: (fs) MappedByteBuffer.load crash with unaligned file-mapping (sol)
|Reviewed-by: chegar, forax
|
|diff -r 5ff8b884a92c -r 24741c4bf300 src/share/classes/java/nio/Bits.java
|--- openjdk.orig/jdk/src/share/classes/java/nio/Bits.java	Tue Jul 27 11:40:46 2010 +0100
|+++ openjdk/jdk/src/share/classes/java/nio/Bits.java	Thu Jul 29 13:08:58 2010 +0100
--------------------------
Patching file openjdk/jdk/src/share/classes/java/nio/Bits.java using Plan A...
Hunk #1 succeeded at 603 (offset 7 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 5ff8b884a92c -r 24741c4bf300 src/share/classes/java/nio/MappedByteBuffer.java
|--- openjdk.orig/jdk/src/share/classes/java/nio/MappedByteBuffer.java	Tue Jul 27 11:40:46 2010 +0100
|+++ openjdk/jdk/src/share/classes/java/nio/MappedByteBuffer.java	Thu Jul 29 13:08:58 2010 +0100
--------------------------
Patching file openjdk/jdk/src/share/classes/java/nio/MappedByteBuffer.java using Plan A...
Hunk #1 succeeded at 25.
Hunk #2 succeeded at 95.
Hunk #3 succeeded at 133.
Hunk #4 succeeded at 152.
Hunk #5 succeeded at 189.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 5ff8b884a92c -r 24741c4bf300 src/solaris/native/java/nio/MappedByteBuffer.c
|--- openjdk.orig/jdk/src/solaris/native/java/nio/MappedByteBuffer.c	Tue Jul 27 11:40:46 2010 +0100
|+++ openjdk/jdk/src/solaris/native/java/nio/MappedByteBuffer.c	Thu Jul 29 13:08:58 2010 +0100
--------------------------
Patching file openjdk/jdk/src/solaris/native/java/nio/MappedByteBuffer.c using Plan A...
Hunk #1 succeeded at 32.
Hunk #2 succeeded at 48 (offset -4 lines).
Hunk #3 succeeded at 65 (offset -4 lines).
Hunk #4 succeeded at 81 (offset -4 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 5ff8b884a92c -r 24741c4bf300 src/windows/native/java/nio/MappedByteBuffer.c
|--- openjdk.orig/jdk/src/windows/native/java/nio/MappedByteBuffer.c	Tue Jul 27 11:40:46 2010 +0100
|+++ openjdk/jdk/src/windows/native/java/nio/MappedByteBuffer.c	Thu Jul 29 13:08:58 2010 +0100
--------------------------
Patching file openjdk/jdk/src/windows/native/java/nio/MappedByteBuffer.c using Plan A...
Hunk #1 succeeded at 31.
Hunk #2 succeeded at 43.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 5ff8b884a92c -r 24741c4bf300 test/java/nio/MappedByteBuffer/Basic.java
|--- openjdk.orig/jdk/test/java/nio/MappedByteBuffer/Basic.java	Tue Jul 27 11:40:46 2010 +0100
|+++ openjdk/jdk/test/java/nio/MappedByteBuffer/Basic.java	Thu Jul 29 13:08:58 2010 +0100
--------------------------
Patching file openjdk/jdk/test/java/nio/MappedByteBuffer/Basic.java using Plan A...
Hunk #1 succeeded at 22 with fuzz 2.
Hunk #2 succeeded at 51 (offset -1 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 5ff8b884a92c -r 24741c4bf300 test/java/nio/MappedByteBuffer/Truncate.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/java/nio/MappedByteBuffer/Truncate.java	Thu Jul 29 13:08:58 2010 +0100
--------------------------
(Creating file openjdk/jdk/test/java/nio/MappedByteBuffer/Truncate.java...)
Patching file openjdk/jdk/test/java/nio/MappedByteBuffer/Truncate.java using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/jtreg-hotspot-bug-6196102.patch
Applying patches/jtreg-hotspot-bug-6196102.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- /dev/null	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/hotspot/test/runtime/6196102/LoopTest.java	2011-02-28 22:06:47.654895000 +0100
--------------------------
(Creating file openjdk/hotspot/test/runtime/6196102/LoopTest.java...)
Patching file openjdk/hotspot/test/runtime/6196102/LoopTest.java using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/jtreg-double-to-string.patch
Applying patches/jtreg-double-to-string.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk-old/jdk/test/java/lang/Double/ToString.java	2011-02-28 10:51:09.454128000 +0100
|+++ openjdk/jdk/test/java/lang/Double/ToString.java	2011-02-28 10:51:09.454128000 +0100
--------------------------
Patching file openjdk/jdk/test/java/lang/Double/ToString.java using Plan A...
Hunk #1 succeeded at 23.
done
Checking patches/openjdk/7023591-AAShapePipe.patch
Applying patches/openjdk/7023591-AAShapePipe.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User prr
|# Date 1299282881 28800
|# Node ID f82f0af7de5bb0e41cb957d654e8a1beaeab0008
|# Parent  01dcb496946e514fe5e61504d0bd2516d6a42783
|7023591: Xrender: java2D font demo - text highlighting tab content is black
|Reviewed-by: flar
|
|diff -r 01dcb496946e -r f82f0af7de5b src/share/classes/sun/java2d/pipe/AAShapePipe.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pipe/AAShapePipe.java	Thu Mar 03 16:06:42 2011 -0800
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/AAShapePipe.java	Fri Mar 04 15:54:41 2011 -0800
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/AAShapePipe.java using Plan A...
Hunk #1 succeeded at 109.
done
Checking patches/openjdk/7027667-AAShapePipeRegTest.patch
Applying patches/openjdk/7027667-AAShapePipeRegTest.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User dlila
|# Date 1300216510 14400
|# Node ID fd8b81c558d307a984ad2dcd06b7de092c3f01f5
|# Parent  87444344d6169cce2ef7fbbf48582728769a8d85
|7027667: clipped aa rectangles are not drawn properly.
|Summary: Already fixed. This is just a regression test for it.
|Reviewed-by: prr
|
|diff -r 87444344d616 -r fd8b81c558d3 test/sun/java2d/pipe/Test7027667.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/sun/java2d/pipe/Test7027667.java	Tue Mar 15 15:15:10 2011 -0400
--------------------------
(Creating file openjdk/jdk/test/sun/java2d/pipe/Test7027667.java...)
Patching file openjdk/jdk/test/sun/java2d/pipe/Test7027667.java using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/openjdk/7019861-AA-regression-fix.patch
Applying patches/openjdk/7019861-AA-regression-fix.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User dlila
|# Date 1300223102 14400
|# Node ID 253f3bc64961944b1886a243a662bd929e9ab605
|# Parent  fd8b81c558d307a984ad2dcd06b7de092c3f01f5
|7019861: Last scanline is skipped in pisces.Renderer.
|Summary: not skipping it anymore.
|Reviewed-by: flar
|
|diff -r fd8b81c558d3 -r 253f3bc64961 src/share/classes/sun/java2d/pisces/Helpers.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pisces/Helpers.java	Tue Mar 15 15:15:10 2011 -0400
|+++ openjdk/jdk/src/share/classes/sun/java2d/pisces/Helpers.java	Tue Mar 15 17:05:02 2011 -0400
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/Helpers.java using Plan A...
Hunk #1 succeeded at 154.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r fd8b81c558d3 -r 253f3bc64961 src/share/classes/sun/java2d/pisces/PiscesTileGenerator.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pisces/PiscesTileGenerator.java	Tue Mar 15 15:15:10 2011 -0400
|+++ openjdk/jdk/src/share/classes/sun/java2d/pisces/PiscesTileGenerator.java	Tue Mar 15 17:05:02 2011 -0400
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/PiscesTileGenerator.java using Plan A...
Hunk #1 succeeded at 191.
Hunk #2 succeeded at 214.
Hunk #3 succeeded at 248.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r fd8b81c558d3 -r 253f3bc64961 src/share/classes/sun/java2d/pisces/Renderer.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pisces/Renderer.java	Tue Mar 15 15:15:10 2011 -0400
|+++ openjdk/jdk/src/share/classes/sun/java2d/pisces/Renderer.java	Tue Mar 15 17:05:02 2011 -0400
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/Renderer.java using Plan A...
Hunk #1 succeeded at 47.
Hunk #2 succeeded at 148.
Hunk #3 succeeded at 157.
Hunk #4 succeeded at 169.
Hunk #5 succeeded at 206.
Hunk #6 succeeded at 262.
Hunk #7 succeeded at 273.
Hunk #8 succeeded at 297.
Hunk #9 succeeded at 354.
Hunk #10 succeeded at 384.
Hunk #11 succeeded at 421.
Hunk #12 succeeded at 445.
Hunk #13 succeeded at 467.
Hunk #14 succeeded at 531.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r fd8b81c558d3 -r 253f3bc64961 src/share/classes/sun/java2d/pisces/Stroker.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pisces/Stroker.java	Tue Mar 15 15:15:10 2011 -0400
|+++ openjdk/jdk/src/share/classes/sun/java2d/pisces/Stroker.java	Tue Mar 15 17:05:02 2011 -0400
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/Stroker.java using Plan A...
Hunk #1 succeeded at 764.
Hunk #2 succeeded at 871.
Hunk #3 succeeded at 938.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r fd8b81c558d3 -r 253f3bc64961 test/sun/java2d/pisces/Renderer/Test7019861.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/sun/java2d/pisces/Renderer/Test7019861.java	Tue Mar 15 17:05:02 2011 -0400
--------------------------
(Creating file openjdk/jdk/test/sun/java2d/pisces/Renderer/Test7019861.java...)
Patching file openjdk/jdk/test/sun/java2d/pisces/Renderer/Test7019861.java using Plan A...
Hunk #1 succeeded at 1.
done
Checking patches/g356743-libpng-1.5.patch
Applying patches/g356743-libpng-1.5.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk.orig/jdk/src/share/native/sun/awt/splashscreen/splashscreen_png.c
|+++ openjdk/jdk/src/share/native/sun/awt/splashscreen/splashscreen_png.c
--------------------------
Patching file openjdk/jdk/src/share/native/sun/awt/splashscreen/splashscreen_png.c using Plan A...
Hunk #1 succeeded at 36.
Hunk #2 succeeded at 71.
done
Checking patches/revert-6885123.patch
Applying patches/revert-6885123.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk.old/langtools/src/share/classes/com/sun/tools/javac/file/RegularFileObject.java	2011-02-28 17:07:28.000000000 +0100
|+++ openjdk/langtools/src/share/classes/com/sun/tools/javac/file/RegularFileObject.java	2011-03-25 10:16:13.646180000 +0100
--------------------------
Patching file openjdk/langtools/src/share/classes/com/sun/tools/javac/file/RegularFileObject.java using Plan A...
Hunk #1 succeeded at 78.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- /dev/null	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/test/javax/tools/JavaFileManager/JavaFileManagerTest.java	2011-03-28 15:51:43.000000000 +0200
--------------------------
(Creating file openjdk/jdk/test/javax/tools/JavaFileManager/JavaFileManagerTest.java...)
Patching file openjdk/jdk/test/javax/tools/JavaFileManager/JavaFileManagerTest.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- /dev/null	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/test/javax/tools/JavaFileManager/JavaFileManagerTest.sh	2011-03-28 15:47:23.000000000 +0200
--------------------------
(Creating file openjdk/jdk/test/javax/tools/JavaFileManager/JavaFileManagerTest.sh...)
Patching file openjdk/jdk/test/javax/tools/JavaFileManager/JavaFileManagerTest.sh using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- /dev/null	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/test/javax/tools/JavaFileManager/test_data/Test.html	2011-03-25 18:19:45.000000000 +0100
--------------------------
(Creating file openjdk/jdk/test/javax/tools/JavaFileManager/test_data/Test.html...)
Patching file openjdk/jdk/test/javax/tools/JavaFileManager/test_data/Test.html using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- /dev/null	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/test/javax/tools/JavaFileManager/test_data/Test.java	2011-03-28 14:53:50.000000000 +0200
--------------------------
(Creating file openjdk/jdk/test/javax/tools/JavaFileManager/test_data/Test.java...)
Patching file openjdk/jdk/test/javax/tools/JavaFileManager/test_data/Test.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- /dev/null	1970-01-01 01:00:00.000000000 +0100
|+++ openjdk/jdk/test/javax/tools/JavaFileManager/test_data/Test.txt	2011-03-28 16:15:09.000000000 +0200
--------------------------
(Creating file openjdk/jdk/test/javax/tools/JavaFileManager/test_data/Test.txt...)
Patching file openjdk/jdk/test/javax/tools/JavaFileManager/test_data/Test.txt using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/langtools/test/tools/javac/api/6411310/Test.java	2011-02-28 17:07:32.000000000 +0100
|+++ /dev/null	2011-03-27 16:20:13.277479669 +0200
--------------------------
Patching file openjdk/langtools/test/tools/javac/api/6411310/Test.java using Plan A...
Hunk #1 succeeded at 0.
done
Checking patches/openjdk/7032388-work_without_cmov_instruction.patch
Applying patches/openjdk/7032388-work_without_cmov_instruction.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/hotspot/src/cpu/x86/vm/assembler_x86.cpp	2011-03-30 11:31:16.408872134 -0700
|+++ openjdk/hotspot/src/cpu/x86/vm/assembler_x86.cpp	2011-03-30 11:31:16.084614406 -0700
--------------------------
Patching file openjdk/hotspot/src/cpu/x86/vm/assembler_x86.cpp using Plan A...
Hunk #1 succeeded at 7723 (offset -46 lines).
Hunk #2 succeeded at 8724 (offset -317 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/hotspot/src/cpu/x86/vm/assembler_x86.hpp	2011-03-30 11:31:17.757655562 -0700
|+++ openjdk/hotspot/src/cpu/x86/vm/assembler_x86.hpp	2011-03-30 11:31:17.553920606 -0700
--------------------------
Patching file openjdk/hotspot/src/cpu/x86/vm/assembler_x86.hpp using Plan A...
Hunk #1 succeeded at 2235 (offset -9 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp	2011-03-30 11:31:18.743456717 -0700
|+++ openjdk/hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp	2011-03-30 11:31:18.541656202 -0700
--------------------------
Patching file openjdk/hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp using Plan A...
Hunk #1 succeeded at 23.
Hunk #2 succeeded at 572 (offset 2 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/hotspot/src/cpu/x86/vm/c1_Runtime1_x86.cpp	2011-03-30 11:31:19.824124145 -0700
|+++ openjdk/hotspot/src/cpu/x86/vm/c1_Runtime1_x86.cpp	2011-03-30 11:31:19.606167752 -0700
--------------------------
Patching file openjdk/hotspot/src/cpu/x86/vm/c1_Runtime1_x86.cpp using Plan A...
Hunk #1 succeeded at 23.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- openjdk/hotspot/src/cpu/x86/vm/templateTable_x86_32.cpp	2011-03-30 11:31:20.910918826 -0700
|+++ openjdk/hotspot/src/cpu/x86/vm/templateTable_x86_32.cpp	2011-03-30 11:31:20.703693030 -0700
--------------------------
Patching file openjdk/hotspot/src/cpu/x86/vm/templateTable_x86_32.cpp using Plan A...
Hunk #1 succeeded at 23.
Hunk #2 succeeded at 1973 (offset 33 lines).
Hunk #3 succeeded at 3504 (offset 33 lines).
done
Checking patches/openjdk/7031385-gcc-register-allocation-fix.patch
Applying patches/openjdk/7031385-gcc-register-allocation-fix.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -ur openjdk.orig/hotspot/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp openjdk/hotspot/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp
|--- openjdk.orig/hotspot/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp	2011-03-31 13:05:19.924400634 -0400
|+++ openjdk/hotspot/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp	2011-03-31 13:06:00.617400605 -0400
--------------------------
Patching file openjdk/hotspot/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp using Plan A...
Hunk #1 succeeded at 93.
Hunk #2 succeeded at 155.
done
Checking patches/openjdk/6986968-crash_on_xim_restart.patch
Applying patches/openjdk/6986968-crash_on_xim_restart.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User omajid
|# Date 1285601403 14400
|# Node ID bbadb9484f537ce1e6ecf6e0d1f130235367c7e4
|# Parent  278c8daa30750577cadb47f7c6c827d2dfb7d0bd
|6986968: Crash on XIM server restart
|Summary: Free XIM data structures on DestroyXIMCallback
|Reviewed-by: naoto
|
|diff -r 278c8daa3075 -r bbadb9484f53 src/solaris/native/sun/awt/awt_InputMethod.c
|--- openjdk/jdk/src/solaris/native/sun/awt/awt_InputMethod.c	Mon Sep 27 13:38:49 2010 +0400
|+++ openjdk/jdk/src/solaris/native/sun/awt/awt_InputMethod.c	Mon Sep 27 11:30:03 2010 -0400
--------------------------
Patching file openjdk/jdk/src/solaris/native/sun/awt/awt_InputMethod.c using Plan A...
Hunk #1 succeeded at 1473.
done
Checking patches/openjdk/7036754-stroker-nan.patch
Applying patches/openjdk/7036754-stroker-nan.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User dlila
|# Date 1303995319 14400
|# Node ID 24f474ad17038b0bef4686c79c8b8de25ab23723
|# Parent  a07c9e09b4caa5690209af460e8c9371b8384cb0
|7036754: NaNs in stroked quadratics.
|Summary: Check for them and remove them.
|Reviewed-by: flar
|
|diff -r a07c9e09b4ca -r 24f474ad1703 src/share/classes/sun/java2d/pisces/Stroker.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pisces/Stroker.java	Wed Apr 27 12:15:34 2011 +0400
|+++ openjdk/jdk/src/share/classes/sun/java2d/pisces/Stroker.java	Thu Apr 28 08:55:19 2011 -0400
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pisces/Stroker.java using Plan A...
Hunk #1 succeeded at 27.
Hunk #2 succeeded at 132.
Hunk #3 succeeded at 219.
Hunk #4 succeeded at 248.
Hunk #5 succeeded at 286.
Hunk #6 succeeded at 315.
Hunk #7 succeeded at 327.
Hunk #8 succeeded at 566.
Hunk #9 succeeded at 583.
Hunk #10 succeeded at 693.
Hunk #11 succeeded at 701.
Hunk #12 succeeded at 821.
Hunk #13 succeeded at 843.
Hunk #14 succeeded at 851.
Hunk #15 succeeded at 893.
Hunk #16 succeeded at 982.
Hunk #17 succeeded at 1005.
Hunk #18 succeeded at 1054.
Hunk #19 succeeded at 1077.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r a07c9e09b4ca -r 24f474ad1703 test/sun/java2d/pisces/Test7036754.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/sun/java2d/pisces/Test7036754.java	Thu Apr 28 08:55:19 2011 -0400
--------------------------
(Creating file openjdk/jdk/test/sun/java2d/pisces/Test7036754.java...)
Patching file openjdk/jdk/test/sun/java2d/pisces/Test7036754.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  Ignoring the trailing garbage.
done
Checking patches/openjdk/pgram-pipe-regression.patch
Applying patches/openjdk/pgram-pipe-regression.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User flar
|# Date 1305155521 25200
|# Node ID f290441b0cb7f5059caab84936b363b1f45e9e2f
|# Parent  85f53467c30ce903c3ea51cfea7759d9c7e39edc
|7043054: REGRESSION: JDK 7 b126 : Wrong userBounds in Paint.createContext()
|Reviewed-by: prr
|
|diff -r 85f53467c30c -r f290441b0cb7 src/share/classes/sun/java2d/opengl/OGLRenderer.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/opengl/OGLRenderer.java	Tue May 10 15:59:01 2011 -0700
|+++ openjdk/jdk/src/share/classes/sun/java2d/opengl/OGLRenderer.java	Wed May 11 16:12:01 2011 -0700
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/opengl/OGLRenderer.java using Plan A...
Hunk #1 succeeded at 118 (offset 16 lines).
Hunk #2 succeeded at 139 (offset 16 lines).
Hunk #3 succeeded at 188 (offset 16 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 85f53467c30c -r f290441b0cb7 src/share/classes/sun/java2d/pipe/AAShapePipe.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pipe/AAShapePipe.java	Tue May 10 15:59:01 2011 -0700
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/AAShapePipe.java	Wed May 11 16:12:01 2011 -0700
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/AAShapePipe.java using Plan A...
Hunk #1 succeeded at 68.
Hunk #2 succeeded at 99.
Hunk #3 succeeded at 122.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 85f53467c30c -r f290441b0cb7 src/share/classes/sun/java2d/pipe/AlphaColorPipe.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pipe/AlphaColorPipe.java	Tue May 10 15:59:01 2011 -0700
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/AlphaColorPipe.java	Wed May 11 16:12:01 2011 -0700
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/AlphaColorPipe.java using Plan A...
Hunk #1 succeeded at 66.
Hunk #2 succeeded at 77.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 85f53467c30c -r f290441b0cb7 src/share/classes/sun/java2d/pipe/BufferedRenderPipe.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pipe/BufferedRenderPipe.java	Tue May 10 15:59:01 2011 -0700
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/BufferedRenderPipe.java	Wed May 11 16:12:01 2011 -0700
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/BufferedRenderPipe.java using Plan A...
Hunk #1 succeeded at 408.
Hunk #2 succeeded at 431.
Hunk #3 succeeded at 458.
Hunk #4 succeeded at 481.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 85f53467c30c -r f290441b0cb7 src/share/classes/sun/java2d/pipe/LoopPipe.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pipe/LoopPipe.java	Tue May 10 15:59:01 2011 -0700
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/LoopPipe.java	Wed May 11 16:12:01 2011 -0700
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/LoopPipe.java using Plan A...
Hunk #1 succeeded at 352.
Hunk #2 succeeded at 364.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 85f53467c30c -r f290441b0cb7 src/share/classes/sun/java2d/pipe/ParallelogramPipe.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pipe/ParallelogramPipe.java	Tue May 10 15:59:01 2011 -0700
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/ParallelogramPipe.java	Wed May 11 16:12:01 2011 -0700
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/ParallelogramPipe.java using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 40.
Hunk #3 succeeded at 67.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 85f53467c30c -r f290441b0cb7 src/share/classes/sun/java2d/pipe/PixelToParallelogramConverter.java
|--- openjdk.orig/jdk/src/share/classes/sun/java2d/pipe/PixelToParallelogramConverter.java	Tue May 10 15:59:01 2011 -0700
|+++ openjdk/jdk/src/share/classes/sun/java2d/pipe/PixelToParallelogramConverter.java	Wed May 11 16:12:01 2011 -0700
--------------------------
Patching file openjdk/jdk/src/share/classes/sun/java2d/pipe/PixelToParallelogramConverter.java using Plan A...
Hunk #1 succeeded at 175.
Hunk #2 succeeded at 194.
Hunk #3 succeeded at 214.
Hunk #4 succeeded at 284.
Hunk #5 succeeded at 319.
Hunk #6 succeeded at 367.
Hunk #7 succeeded at 386.
Hunk #8 succeeded at 423.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 85f53467c30c -r f290441b0cb7 src/windows/classes/sun/java2d/d3d/D3DRenderer.java
|--- openjdk.orig/jdk/src/windows/classes/sun/java2d/d3d/D3DRenderer.java	Tue May 10 15:59:01 2011 -0700
|+++ openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DRenderer.java	Wed May 11 16:12:01 2011 -0700
--------------------------
Patching file openjdk/jdk/src/windows/classes/sun/java2d/d3d/D3DRenderer.java using Plan A...
Hunk #1 succeeded at 118 (offset 16 lines).
Hunk #2 succeeded at 139 (offset 16 lines).
Hunk #3 succeeded at 189 (offset 16 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -r 85f53467c30c -r f290441b0cb7 test/java/awt/Paint/PgramUserBoundsTest.java
|--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
|+++ openjdk/jdk/test/java/awt/Paint/PgramUserBoundsTest.java	Wed May 11 16:12:01 2011 -0700
--------------------------
(Creating file openjdk/jdk/test/java/awt/Paint/PgramUserBoundsTest.java...)
Patching file openjdk/jdk/test/java/awt/Paint/PgramUserBoundsTest.java using Plan A...
Hunk #1 succeeded at 1.
Hmm...  Ignoring the trailing garbage.
done
Checking patches/openjdk/7034464-hugepage.patch
Applying patches/openjdk/7034464-hugepage.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|# HG changeset patch
|# User iveresov
|# Date 1303344724 25200
|# Node ID 139667d9836ae218ab06a74d5813a5a700a076c9
|# Parent  49a67202bc671d23d719c9e14752d80295a9e8f6
|7034464: Support transparent large pages on Linux
|Summary: Support transparent huge pages on Linux available since 2.6.38
|Reviewed-by: iveresov, ysr
|Contributed-by: aph at redhat.com
|diff -u -r openjdk.patched/hotspot/src/os/linux/vm/globals_linux.hpp openjdk/hotspot/src/os/linux/vm/globals_linux.hpp
|--- openjdk.patched/hotspot/src/os/linux/vm/globals_linux.hpp	2011-03-16 02:30:16.000000000 +0000
|+++ openjdk/hotspot/src/os/linux/vm/globals_linux.hpp	2011-05-04 11:57:15.083470027 +0100
--------------------------
Patching file openjdk/hotspot/src/os/linux/vm/globals_linux.hpp using Plan A...
Hunk #1 succeeded at 29.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -u -r openjdk.patched/hotspot/src/os/linux/vm/os_linux.cpp openjdk/hotspot/src/os/linux/vm/os_linux.cpp
|--- openjdk.patched/hotspot/src/os/linux/vm/os_linux.cpp	2011-05-03 14:32:54.285722656 +0100
|+++ openjdk/hotspot/src/os/linux/vm/os_linux.cpp	2011-05-09 14:31:51.358502774 +0100
--------------------------
Patching file openjdk/hotspot/src/os/linux/vm/os_linux.cpp using Plan A...
Hunk #1 succeeded at 2495.
Hunk #2 succeeded at 2894.
Hunk #3 succeeded at 2948.
Hunk #4 succeeded at 2958.
Hunk #5 succeeded at 2980.
Hunk #6 succeeded at 3047.
Hunk #7 succeeded at 5053.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -u -r openjdk.patched/hotspot/src/os/linux/vm/os_linux.cpp.orig openjdk/hotspot/src/os/linux/vm/os_linux.cpp.orig
|--- openjdk.patched/hotspot/src/os/linux/vm/os_linux.cpp.orig	2011-05-03 14:32:53.972649764 +0100
|+++ openjdk/hotspot/src/os/linux/vm/os_linux.cpp.orig	2011-05-04 11:57:15.085470494 +0100
--------------------------
Patching file openjdk/hotspot/src/os/linux/vm/os_linux.cpp.orig using Plan A...
Reversed (or previously applied) patch detected!  Assume -R? [y] 

From aph at redhat.com  Tue Apr 17 02:41:27 2012
From: aph at redhat.com (Andrew Haley)
Date: Tue, 17 Apr 2012 10:41:27 +0100
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its name should be openjdk-plugin !
In-Reply-To: <CACGw4H6-e=67ZkdwDfj4S9fMNO5Ptb-rDi4hTmtO7W9O6FaFsA@mail.gmail.com>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>
	<4F8B0820.7050001@redhat.com>
	<CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>
	<87lilwsule.fsf@mid.deneb.enyo.de>
	<CACGw4H4c+dYKtNFaP+UKJg3ZEtMp0RZGavGRMjvbms9PGJoErg@mail.gmail.com>
	<87aa2cstbv.fsf@mid.deneb.enyo.de>
	<CACGw4H5yWav9s92ttbEdJ2CGDf1TO_FW+MV2sefHOHgUvMr72A@mail.gmail.com>
	<4F8BD917.9070500@redhat.com> <4F8BE44E.5070003@redhat.com>
	<4F8BE6E4.7090609@redhat.com>
	<CACGw4H4K+oyHR9jeLoqnsQbGCtSPig-FbpbdxY85FEiWyD01kg@mail.gmail.com>
	<4F8BF674.4020809@redhat.com>
	<CACGw4H6-e=67ZkdwDfj4S9fMNO5Ptb-rDi4hTmtO7W9O6FaFsA@mail.gmail.com>
Message-ID: <4F8D3AC7.1000305@redhat.com>

I think we should open a fedora bug for this.  Something along the
lines of "plugin is not installed by default and is hard for a user
to find."

Andrew.


From adinn at redhat.com  Tue Apr 17 03:49:23 2012
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 17 Apr 2012 11:49:23 +0100
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its name should be openjdk-plugin !
In-Reply-To: <4F8D3AC7.1000305@redhat.com>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>
	<4F8B0820.7050001@redhat.com>
	<CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>
	<87lilwsule.fsf@mid.deneb.enyo.de>
	<CACGw4H4c+dYKtNFaP+UKJg3ZEtMp0RZGavGRMjvbms9PGJoErg@mail.gmail.com>
	<87aa2cstbv.fsf@mid.deneb.enyo.de>
	<CACGw4H5yWav9s92ttbEdJ2CGDf1TO_FW+MV2sefHOHgUvMr72A@mail.gmail.com>
	<4F8BD917.9070500@redhat.com> <4F8BE44E.5070003@redhat.com>
	<4F8BE6E4.7090609@redhat.com>
	<CACGw4H4K+oyHR9jeLoqnsQbGCtSPig-FbpbdxY85FEiWyD01kg@mail.gmail.com>
	<4F8BF674.4020809@redhat.com>
	<CACGw4H6-e=67ZkdwDfj4S9fMNO5Ptb-rDi4hTmtO7W9O6FaFsA@mail.gmail.com>
	<4F8D3AC7.1000305@redhat.com>
Message-ID: <4F8D4AB3.5070909@redhat.com>

On 17/04/12 10:41, Andrew Haley wrote:
> I think we should open a fedora bug for this.  Something along the
> lines of "plugin is not installed by default and is hard for a user
> to find."

I don't disagree with this but I'll note two things about the 'use case'
Fernando offered that is driving this change.

First, if you type openjdk into the Fedora (16) Add/Remove Software GUI
the plug-in /is/ found (it gets listed as 'Extra packages for OpenJDK'
or something like that).

Second, his example of 'yum install openjdk*' is misleading. You can
only wildcard yum info/list. If you do use 'yum info' then it appears to
search the package names using the lcase version of what you type in.

I don't want to sound like I am nit-picking (although I am sure I do). I
think it is important that we present a case to Sun that is clear and
correct.

regards,


Andrew Dinn
-----------


From fcassia at gmail.com  Tue Apr 17 04:47:06 2012
From: fcassia at gmail.com (Fernando Cassia)
Date: Tue, 17 Apr 2012 08:47:06 -0300
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream, its
	name should be openjdk-plugin !
In-Reply-To: <4F8D4AB3.5070909@redhat.com>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>
	<4F8B0820.7050001@redhat.com>
	<CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>
	<87lilwsule.fsf@mid.deneb.enyo.de>
	<CACGw4H4c+dYKtNFaP+UKJg3ZEtMp0RZGavGRMjvbms9PGJoErg@mail.gmail.com>
	<87aa2cstbv.fsf@mid.deneb.enyo.de>
	<CACGw4H5yWav9s92ttbEdJ2CGDf1TO_FW+MV2sefHOHgUvMr72A@mail.gmail.com>
	<4F8BD917.9070500@redhat.com> <4F8BE44E.5070003@redhat.com>
	<4F8BE6E4.7090609@redhat.com>
	<CACGw4H4K+oyHR9jeLoqnsQbGCtSPig-FbpbdxY85FEiWyD01kg@mail.gmail.com>
	<4F8BF674.4020809@redhat.com>
	<CACGw4H6-e=67ZkdwDfj4S9fMNO5Ptb-rDi4hTmtO7W9O6FaFsA@mail.gmail.com>
	<4F8D3AC7.1000305@redhat.com> <4F8D4AB3.5070909@redhat.com>
Message-ID: <CACGw4H7BmYzt9SZN6iJyfpsjAnQ4yDKuELELXFr-UM33SPmkXQ@mail.gmail.com>

On Tue, Apr 17, 2012 at 07:49, Andrew Dinn <adinn at redhat.com> wrote:

> Second, his example of 'yum install openjdk*' is misleading. You can
> only wildcard yum info/list
>

Andrew,

I just did a "yum install packagename*" on several packages in my server
box running
Fedora 17 (beta, rc3).

I will have to do a seach in the bash_history file... but I do remember I
did use wildcards on a couple ocassions...

oh,wait
http://forums.fedoraforum.org/showthread.php?t=98217

FC
-- 
During times of Universal Deceit, telling the truth becomes a revolutionary
act
- George Orwell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120417/456c9542/attachment.html 

From ahughes at redhat.com  Tue Apr 17 04:51:23 2012
From: ahughes at redhat.com (Andrew Hughes)
Date: Tue, 17 Apr 2012 07:51:23 -0400 (EDT)
Subject: porting icedtea6 to FreeBSD
In-Reply-To: <20120417064043.GA17160@dormouse.experts-exchange.com>
Message-ID: <7f930db0-bfbd-4a85-9f8e-8c357bfb710a@zmail17.collab.prod.int.phx2.redhat.com>

----- Original Message -----
> On Mon, Apr 16, 2012 at 09:59:00AM -0400, Andrew Hughes thus spake:
> >> Any thoughts on any of this?
> >> Thanks, again.
> >>
> >> -jgh
> >
> >What are you doing here?
> >
> >/usr/bin/sed -i.bak -e 's|--dry-run||g'
> >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.am
> >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.in
> >/usr/bin/sed -i.bak -e 's|--check|-q|g'
> >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.am
> >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.in
> >
> >If you're removing --dry-run, you're going to be applying the patch
> >twice, which is why it's failing.
> >--
> >Andrew :)
> 
> I've modified this to test the patch which in FreeBSD is the "-C"
> switch,
> and the "-q" is for SHASUM's to only output the hash.
> 
> I was able to get much further in the build! Any thoughts on why this
> patch
> was seen as already applied?
> 

Because the build tests the patch, then applies it if that passes.  If you
removed --dry-run from the first invocation and didn't replace it with -C,
you'd be applying the patch twice instead.

> -jgh
> 
> --
> Jason Helfman         | FreeBSD Committer
> jgh at FreeBSD.org       | http://people.freebsd.org/~jgh
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From adinn at redhat.com  Tue Apr 17 05:35:00 2012
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 17 Apr 2012 13:35:00 +0100
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its name should be openjdk-plugin !
In-Reply-To: <CACGw4H7BmYzt9SZN6iJyfpsjAnQ4yDKuELELXFr-UM33SPmkXQ@mail.gmail.com>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>
	<4F8B0820.7050001@redhat.com>
	<CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>
	<87lilwsule.fsf@mid.deneb.enyo.de>
	<CACGw4H4c+dYKtNFaP+UKJg3ZEtMp0RZGavGRMjvbms9PGJoErg@mail.gmail.com>
	<87aa2cstbv.fsf@mid.deneb.enyo.de>
	<CACGw4H5yWav9s92ttbEdJ2CGDf1TO_FW+MV2sefHOHgUvMr72A@mail.gmail.com>
	<4F8BD917.9070500@redhat.com> <4F8BE44E.5070003@redhat.com>
	<4F8BE6E4.7090609@redhat.com>
	<CACGw4H4K+oyHR9jeLoqnsQbGCtSPig-FbpbdxY85FEiWyD01kg@mail.gmail.com>
	<4F8BF674.4020809@redhat.com>
	<CACGw4H6-e=67ZkdwDfj4S9fMNO5Ptb-rDi4hTmtO7W9O6FaFsA@mail.gmail.com>
	<4F8D3AC7.1000305@redhat.com> <4F8D4AB3.5070909@redhat.com>
	<CACGw4H7BmYzt9SZN6iJyfpsjAnQ4yDKuELELXFr-UM33SPmkXQ@mail.gmail.com>
Message-ID: <4F8D6374.9010703@redhat.com>

On 17/04/12 12:47, Fernando Cassia wrote:
> I just did a "yum install packagename*" on several packages in my server
> box running
> Fedora 17 (beta, rc3).

Yes, you are correct -- I was misreading the error I got when I ran this
command

  [root at sputstik ~]# yum install openjdk*
  Loaded plugins: langpacks, presto, refresh-packagekit
  Setting up Install Process
  No package openjdk* available.
  Error: Nothing to do
  [root at sputstik ~]#

The problem is not the wildcard itself, rather that the pattern openjdk*
does not match an actual package. The following does work

  [root at sputstik ~]# yum install *openjdk*
  Loaded plugins: langpacks, presto, refresh-packagekit
  Setting up Install Process
  Package 1:java-1.6.0-openjdk-javadoc-1.6.0.0-65.1.11.1.fc16.x86_64
already installed and latest version
  Package 1:java-1.6.0-openjdk-devel-1.6.0.0-65.1.11.1.fc16.x86_64
already installed and latest version
  . . .

regards,


Andrew Dinn
-----------
Principal Software Engineer
Red Hat UK Ltd
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Mark Hegarty (Ireland), Matt Parson
(USA), Charlie Peters (USA)


From ptisnovs at icedtea.classpath.org  Tue Apr 17 05:34:28 2012
From: ptisnovs at icedtea.classpath.org (ptisnovs at icedtea.classpath.org)
Date: Tue, 17 Apr 2012 12:34:28 +0000
Subject: /hg/gfx-test: * src/org/gfxtest/reporter/Reporter.java:
Message-ID: <hg.2bd442a17073.1334666068.-6248649288953172555@icedtea.classpath.org>

changeset 2bd442a17073 in /hg/gfx-test
details: http://icedtea.classpath.org/hg/gfx-test?cmd=changeset;node=2bd442a17073
author: Pavel Tisnovsky <ptisnovs at redhat.com>
date: Tue Apr 17 14:37:07 2012 +0200

	* src/org/gfxtest/reporter/Reporter.java:
		* src/org/gfxtest/reporter/ReporterConfiguration.java:
		* src/org/gfxtest/reporter/TestResult.java:
		Code and JavaDoc improvements.


diffstat:

 ChangeLog                                           |    7 +
 src/org/gfxtest/reporter/Reporter.java              |  124 +++++++++++++++++--
 src/org/gfxtest/reporter/ReporterConfiguration.java |   33 ++++-
 src/org/gfxtest/reporter/TestResult.java            |   78 ++++++++++++-
 4 files changed, 223 insertions(+), 19 deletions(-)

diffs (481 lines):

diff -r 31509443dff8 -r 2bd442a17073 ChangeLog
--- a/ChangeLog	Mon Apr 16 11:27:52 2012 +0200
+++ b/ChangeLog	Tue Apr 17 14:37:07 2012 +0200
@@ -1,3 +1,10 @@
+2012-04-17  Pavel Tisnovsky  <ptisnovs at redhat.com>
+
+	* src/org/gfxtest/reporter/Reporter.java:
+	* src/org/gfxtest/reporter/ReporterConfiguration.java:
+	* src/org/gfxtest/reporter/TestResult.java:
+	Code and JavaDoc improvements.
+
 2012-04-16  Pavel Tisnovsky  <ptisnovs at redhat.com>
 
 	* src/org/gfxtest/testsuites/PrintTestBasic.java:
diff -r 31509443dff8 -r 2bd442a17073 src/org/gfxtest/reporter/Reporter.java
--- a/src/org/gfxtest/reporter/Reporter.java	Mon Apr 16 11:27:52 2012 +0200
+++ b/src/org/gfxtest/reporter/Reporter.java	Tue Apr 17 14:37:07 2012 +0200
@@ -65,18 +65,39 @@
      */
     private static final String DEFAULT_ENCODING = "UTF-8";
 
+    /**
+     * Instance of logger class.
+     */
     private Log log = null;
 
+    /**
+     * Configuration of test reporter.
+     */
     private ReporterConfiguration configuration = null;
 
+    /**
+     * Directory where HTML templates are stored.
+     */
     private static final String TEMPLATE_DIR = "templates";
 
+    /**
+     * Name of the main HTML template.
+     */
     private static final String INPUT_FILE_NAME = "template_test_result.html";
 
+    /**
+     * Name of generated HTML file.
+     */
     private static final String OUTPUT_FILE_NAME = "index.html";
 
+    /**
+     * Names of special tests.
+     */
     private static final String[] SPECTESTS = new String[] {"BlankImage", "SpecialCases"};
 
+    /**
+     * Names of tested entities.
+     */
     private static final String[] ENTITIES = new String[] {
     	"Lines",
     	"Polylines",
@@ -89,6 +110,9 @@
     	"Arcs"
     };
 
+    /**
+     * Names of rendering styles.
+     */
     private static final String[] STYLES = new String[] {
     	"Normal",
     	"Filled",
@@ -99,15 +123,22 @@
 
     /**
      * Write report writer duration to the log file.
-     *
-     * @param t1 time when the test suite has been started
-     * @param t2 time when the test suite was completed
+     * 
+     * @param t1
+     *            time when the test suite has been started
+     * @param t2
+     *            time when the test suite was completed
      */
     private void printDuration(long t1, long t2)
     {
         this.log.logSet("duration", Long.valueOf(t2-t1)); //$NON-NLS-1$
     }
 
+    /**
+     * Do the report.
+     *
+     * @param args command line arguments
+     */
     private void doReport(String[] args)
     {
         BufferedReader input = null;
@@ -127,9 +158,11 @@
             output = new BufferedWriter(writer);
             writeHtmlHeader(input, output);
             writeHeaderForCommonTests(output);
+            // loop over all entity types
             for (String entity : ENTITIES)
             {
                 writeEntityHeader(output, entity);
+                // loop over all graphics styles
                 for (String style : STYLES)
                 {
                     String testSuiteName = style + entity;
@@ -140,6 +173,7 @@
                 output.write("</tr>\n");
             }
             output.write("<tr><td colspan='5'>&nbsp;</td>\n");
+            // special tests has to be done separately
             for (String entity : SPECTESTS)
             {
                 writeEntityHeader(output, entity);
@@ -161,23 +195,40 @@
         }
         finally
         {
-            try
-            {
-                if (output != null)
-                {
-                    output.close();
-                }
-            }
-            catch (IOException e)
-            {
-                e.printStackTrace();
-            }
+            closeOutputWriter(output);
             long t2 = System.currentTimeMillis();
             this.log.logEnd("report"); //$NON-NLS-1$
             printDuration(t1, t2);
         }
     }
 
+    /**
+     * Try to close output buffered writer.
+     *
+     * @param output
+     */
+    private void closeOutputWriter(BufferedWriter output)
+    {
+        try
+        {
+            // close output file
+            if (output != null)
+            {
+                output.close();
+            }
+        }
+        catch (IOException e)
+        {
+            e.printStackTrace();
+        }
+    }
+
+    /**
+     * Write header for each test to a HTML file.
+     *
+     * @param output
+     * @throws IOException
+     */
     private void writeHeaderForCommonTests(BufferedWriter output) throws IOException
     {
         output.write("<tr><td class='value'>Entity</td>");
@@ -188,11 +239,26 @@
         output.write("</tr>\n");
     }
 
+    /**
+     * Write header for given graphics entity.
+     *
+     * @param output
+     * @param entity
+     * @throws IOException
+     */
     private void writeEntityHeader(BufferedWriter output, String entity) throws IOException
     {
         output.write("<tr><td class='key'>" + entity +"</td>");
     }
 
+    /**
+     * Write result for one test suite or an 'x' character when the test did not run.
+     *
+     * @param output
+     * @param testResult
+     * @param testSuiteName
+     * @throws IOException
+     */
     private void writeTestResult(BufferedWriter output, TestResult testResult, String testSuiteName) throws IOException
     {
         if (testResult == null)
@@ -205,6 +271,13 @@
         }
     }
 
+    /**
+     * Write HTML header which is read from a HTML template.
+     *
+     * @param input
+     * @param output
+     * @throws IOException
+     */
     private void writeHtmlHeader(BufferedReader input, BufferedWriter output) throws IOException
     {
         String line;
@@ -215,6 +288,13 @@
         }
     }
 
+    /**
+     * Write HTML footer which is read from a HTML template.
+     * 
+     * @param input
+     * @param output
+     * @throws IOException
+     */
     private void writeHtmlFooter(BufferedReader input, BufferedWriter output) throws IOException
     {
         String line;
@@ -225,6 +305,11 @@
         }
     }
 
+    /**
+     * Read all test results a and store them into a map.
+     *
+     * @return
+     */
     private Map<String, TestResult> readAllTestResults()
     {
         Map<String, TestResult> results = new HashMap<String, TestResult>();
@@ -248,6 +333,14 @@
         return results;
     }
 
+    /**
+     * Read and process test result from the file "results.xml".
+     * 
+     * @param resultDirectory
+     *            directory containing test result(s)
+     * 
+     * @return results of one test run
+     */
     @SuppressWarnings({ "boxing" })
     private TestResult readTestResult(File resultDirectory)
     {
@@ -261,6 +354,7 @@
             DocumentBuilder builder = DocumentBuilderFactory.newInstance().newDocumentBuilder();
             Document document = builder.parse(resultFile);
             NodeList nodes = document.getElementsByTagName("test");
+            // read all nodes under node "test"
             for (int i = 0; i < nodes.getLength(); i++)
             {
                 Element testNode = (Element) nodes.item(i);
@@ -308,6 +402,8 @@
     }
 
     /**
+     * Entry to this application.
+     *
      * @param args
      */
     public static void main(String[] args)
diff -r 31509443dff8 -r 2bd442a17073 src/org/gfxtest/reporter/ReporterConfiguration.java
--- a/src/org/gfxtest/reporter/ReporterConfiguration.java	Mon Apr 16 11:27:52 2012 +0200
+++ b/src/org/gfxtest/reporter/ReporterConfiguration.java	Tue Apr 17 14:37:07 2012 +0200
@@ -1,7 +1,7 @@
 /*
   Java gfx-test framework
 
-   Copyright (C) 2010, 2011  Red Hat
+   Copyright (C) 2010, 2011, 2012  Red Hat
 
 This file is part of IcedTea.
 
@@ -47,9 +47,11 @@
 import org.gfxtest.common.ConfigurationException;
 import org.gfxtest.framework.Log;
 
+
+
 /**
- * Configuration for graphics tests reporter.
- *
+ * Instance of this class contain configuration for graphics tests reporter.
+ * 
  * @author Pavel Tisnovsky
  */
 public class ReporterConfiguration extends Configuration
@@ -64,11 +66,23 @@
      */
     private File outputPath;
 
+    /**
+     * Constructor for this class.
+     * 
+     * @param args
+     *            command line parameters
+     * @param log
+     * @throws ConfigurationException
+     *             this exception is thrown in case of any configuration problem
+     */
     public ReporterConfiguration(String[] args, Log log) throws ConfigurationException
     {
         super(args, log);
     }
 
+    /**
+     * Prints all configuration parameters.
+     */
     @SuppressWarnings("nls")
     @Override
     protected void printParameters()
@@ -77,6 +91,9 @@
         this.log.logSet("output path", this.outputPath);
     }
 
+    /**
+     * Read all command line parameters from std. args.
+     */
     @Override
     protected void readCommandLineParameters(String[] args) throws ConfigurationException
     {
@@ -85,11 +102,21 @@
         this.outputPath = new File(getStringParameter(options, "o")); //$NON-NLS-1$
     }
 
+    /**
+     * Returns input path.
+     *
+     * @return input path
+     */
     public File getInputPath()
     {
         return this.inputPath;
     }
 
+    /**
+     * Returns output path.
+     * 
+     * @return output path
+     */
     public File getOutputPath()
     {
         return this.outputPath;
diff -r 31509443dff8 -r 2bd442a17073 src/org/gfxtest/reporter/TestResult.java
--- a/src/org/gfxtest/reporter/TestResult.java	Mon Apr 16 11:27:52 2012 +0200
+++ b/src/org/gfxtest/reporter/TestResult.java	Tue Apr 17 14:37:07 2012 +0200
@@ -1,7 +1,7 @@
 /*
   Java gfx-test framework
 
-   Copyright (C) 2010, 2011  Red Hat
+   Copyright (C) 2010, 2011, 2012  Red Hat
 
 This file is part of IcedTea.
 
@@ -40,47 +40,121 @@
 
 package org.gfxtest.reporter;
 
+/**
+ * Instances of this class contain results of one test run.
+ *
+ * @author Pavel Tisnovsky
+ */
 public class TestResult
 {
+    /**
+     * Total test run.
+     */
     private int totalTests;
+
+    /**
+     * Number of images which are the same after comparison.
+     */
     private int sameImages;
+
+    /**
+     * Number of images which are different after comparison.
+     */
     private int differentImages;
 
+    /**
+     * Empty constructor
+     */
     public TestResult()
     {
-        // empty
+        // empty as expected
     }
 
+    /**
+     * Constructor.
+     * 
+     * @param totalTests
+     *            total test run
+     * @param sameImages
+     *            number of images which are the same after comparison
+     * @param differentImages
+     *            number of images which are different after comparison
+     */
+    public TestResult(int totalTests, int sameImages, int differentImages)
+    {
+        super();
+        // set all attributes
+        setTotalTests(totalTests);
+        setSameImages(sameImages);
+        setDifferentImages(differentImages);
+    }
+
+    /**
+     * Getter for an attribute totalTests.
+     * 
+     * @return value of an attribute totalTests
+     */
     public int getTotalTests()
     {
         return this.totalTests;
     }
 
+    /**
+     * Setter for an attribute totalTests.
+     * 
+     * @param totalTests
+     *            new value of an attribute totalTests
+     */
     public void setTotalTests(int totalTests)
     {
         this.totalTests = totalTests;
     }
 
+    /**
+     * Getter for an attribute sameImages.
+     * 
+     * @return value of an attribute sameImages
+     */
     public int getSameImages()
     {
         return this.sameImages;
     }
 
+    /**
+     * Setter for an attribute sameImages.
+     *
+     * @param sameImages
+     *            new value of an attribute sameImages
+     */
     public void setSameImages(int sameImages)
     {
         this.sameImages = sameImages;
     }
 
+    /**
+     * Getter for an attribute differentImages.
+     * 
+     * @return value of an attribute differentImages
+     */
     public int getDifferentImages()
     {
         return this.differentImages;
     }
 
+    /**
+     * Setter for an attribute differentImages.
+     *
+     * @param differentImages
+     *            new value of an attribute differentImages
+     */
     public void setDifferentImages(int differentImages)
     {
         this.differentImages = differentImages;
     }
 
+    /**
+     * Returns string containing test results.
+     */
     @SuppressWarnings({ "boxing", "nls" })
     @Override
     public String toString()


From ptisnovs at redhat.com  Tue Apr 17 05:46:30 2012
From: ptisnovs at redhat.com (Pavel Tisnovsky)
Date: Tue, 17 Apr 2012 14:46:30 +0200
Subject: [rfc][icedtea-web] rewritten xfork test
In-Reply-To: <4F83F94C.5020801@redhat.com>
References: <4F6B1821.2040600@redhat.com> <4F7F0AB2.8070201@redhat.com>
	<4F83F94C.5020801@redhat.com>
Message-ID: <4F8D6626.50701@redhat.com>

Jiri Vanek wrote:
> On 04/06/2012 05:24 PM, Pavel Tisnovsky wrote:
>> Jiri Vanek wrote:
>>> Inspired by Omair's effort to reduce failing tests, I have rewritten
>>> deadlock tests, which were failing quite randomly in half of the cases.
>>> It was caused by delayed removing of zombies after process have
>>> time-outed.
>>>
>>> By this patch, ignorelist which I have proposed two days ago (and will
>>> do again soon as separate patch) to ignore no-testable classes (eg
>>> interfaces), and fixes from [RFC][icedtea-web] fixes to reproducer
>>> engine, we will be on three  failing reproducers ("spaces" ) and  with
>>> occasional cache test fill.
>>>
>>> All those five -  two sometimes, three regularly - failing reproducers
>>> are the same issue we are talking  in [icedtea-web] RFC: disable tests
>>> that are known to fail thread. - they are representing issue., but...:)
>>>
>>>
>>>
>>> 2012-03-22  Jiri Vanek<jvanek at redhat.com>
>>>
>>>      Rewritten DeadLockTestTest to stop failing in more then 1/2 of
>>> cases
>>>      All assassinated processes were hanging as zombies, killed
>>> forcibly by
>>>      kill -9 now.
>>>      *
>>> /tests/jnlp_tests/simple/deadlocktest/testcases/DeadLockTestTest.java:
>>>      (countJavaInstances) now return pids of found javas.
>>>      (killDiff) new method killing zombie javas forcibly.
>>>
>>
>> Hi Jiri,
>>
>> could you please fix following typos in the test tool?
>>
>> "This process is hanging more th_e_n"
>>
>> "...but isnt!"
>>            ^    (on more places)
>>
>> "proces inside background deadlock cant be null. Was."
>>                                       ^           It ^
>>
>> "lunched JVMs must be exactly 2"
>>    ^  (this one is funny :-)
>>
> 
> Yap. fixed. The changes which were not part of this changeset but were
> noticed will follow as additional changeset.
> 
> Ok now?
> 
> Thanx foe check.
>  J.
>>
>> Thank you in advance,
>> Pavel
> 


Hi Jiri,

your latest changes look ok.

Thank you,
Pavel


From aph at redhat.com  Tue Apr 17 05:40:04 2012
From: aph at redhat.com (Andrew Haley)
Date: Tue, 17 Apr 2012 13:40:04 +0100
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its name should be openjdk-plugin !
In-Reply-To: <4F8D4AB3.5070909@redhat.com>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>
	<4F8B0820.7050001@redhat.com>
	<CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>
	<87lilwsule.fsf@mid.deneb.enyo.de>
	<CACGw4H4c+dYKtNFaP+UKJg3ZEtMp0RZGavGRMjvbms9PGJoErg@mail.gmail.com>
	<87aa2cstbv.fsf@mid.deneb.enyo.de>
	<CACGw4H5yWav9s92ttbEdJ2CGDf1TO_FW+MV2sefHOHgUvMr72A@mail.gmail.com>
	<4F8BD917.9070500@redhat.com> <4F8BE44E.5070003@redhat.com>
	<4F8BE6E4.7090609@redhat.com>
	<CACGw4H4K+oyHR9jeLoqnsQbGCtSPig-FbpbdxY85FEiWyD01kg@mail.gmail.com>
	<4F8BF674.4020809@redhat.com>
	<CACGw4H6-e=67ZkdwDfj4S9fMNO5Ptb-rDi4hTmtO7W9O6FaFsA@mail.gmail.com>
	<4F8D3AC7.1000305@redhat.com> <4F8D4AB3.5070909@redhat.com>
Message-ID: <4F8D64A4.7080109@redhat.com>

On 04/17/2012 11:49 AM, Andrew Dinn wrote:
> On 17/04/12 10:41, Andrew Haley wrote:
>> I think we should open a fedora bug for this.  Something along the
>> lines of "plugin is not installed by default and is hard for a user
>> to find."
> 
> I don't disagree with this but I'll note two things about the 'use case'
> Fernando offered that is driving this change.
> 
> First, if you type openjdk into the Fedora (16) Add/Remove Software GUI
> the plug-in /is/ found (it gets listed as 'Extra packages for OpenJDK'
> or something like that).
> 
> Second, his example of 'yum install openjdk*' is misleading. You can
> only wildcard yum info/list. If you do use 'yum info' then it appears to
> search the package names using the lcase version of what you type in.
> 
> I don't want to sound like I am nit-picking (although I am sure I do). I
> think it is important that we present a case to Sun that is clear and
> correct.

I don't think we have to present anything to Sun/Oracle.  It's a
problem we can fix in Fedora AFAICS.

Andrew.


From ptisnovs at redhat.com  Tue Apr 17 05:58:38 2012
From: ptisnovs at redhat.com (Pavel Tisnovsky)
Date: Tue, 17 Apr 2012 14:58:38 +0200
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its name should be openjdk-plugin !
In-Reply-To: <4F8D6374.9010703@redhat.com>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>	<4F8B0820.7050001@redhat.com>	<CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>	<87lilwsule.fsf@mid.deneb.enyo.de>	<CACGw4H4c+dYKtNFaP+UKJg3ZEtMp0RZGavGRMjvbms9PGJoErg@mail.gmail.com>	<87aa2cstbv.fsf@mid.deneb.enyo.de>	<CACGw4H5yWav9s92ttbEdJ2CGDf1TO_FW+MV2sefHOHgUvMr72A@mail.gmail.com>	<4F8BD917.9070500@redhat.com>
	<4F8BE44E.5070003@redhat.com>	<4F8BE6E4.7090609@redhat.com>	<CACGw4H4K+oyHR9jeLoqnsQbGCtSPig-FbpbdxY85FEiWyD01kg@mail.gmail.com>	<4F8BF674.4020809@redhat.com>	<CACGw4H6-e=67ZkdwDfj4S9fMNO5Ptb-rDi4hTmtO7W9O6FaFsA@mail.gmail.com>	<4F8D3AC7.1000305@redhat.com>
	<4F8D4AB3.5070909@redhat.com>	<CACGw4H7BmYzt9SZN6iJyfpsjAnQ4yDKuELELXFr-UM33SPmkXQ@mail.gmail.com>
	<4F8D6374.9010703@redhat.com>
Message-ID: <4F8D68FE.70503@redhat.com>

Andrew Dinn wrote:
> On 17/04/12 12:47, Fernando Cassia wrote:
>> I just did a "yum install packagename*" on several packages in my server
>> box running
>> Fedora 17 (beta, rc3).
> 
> Yes, you are correct -- I was misreading the error I got when I ran this
> command
> 
>   [root at sputstik ~]# yum install openjdk*
>   Loaded plugins: langpacks, presto, refresh-packagekit
>   Setting up Install Process
>   No package openjdk* available.
>   Error: Nothing to do
>   [root at sputstik ~]#
> 
> The problem is not the wildcard itself, rather that the pattern openjdk*
> does not match an actual package. The following does work
> 
>   [root at sputstik ~]# yum install *openjdk*

AFAIK it's still not 100% correct, because shell could in some circumstances
expand *openjdk* into file list (depending on contents of `pwd` of course).
Safer is to use "*openjdk*"

>   Loaded plugins: langpacks, presto, refresh-packagekit
>   Setting up Install Process
>   Package 1:java-1.6.0-openjdk-javadoc-1.6.0.0-65.1.11.1.fc16.x86_64
> already installed and latest version
>   Package 1:java-1.6.0-openjdk-devel-1.6.0.0-65.1.11.1.fc16.x86_64
> already installed and latest version
>   . . .
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> Principal Software Engineer
> Red Hat UK Ltd
> Registered in UK and Wales under Company Registration No. 3798903
> Directors: Michael Cunningham (USA), Mark Hegarty (Ireland), Matt Parson
> (USA), Charlie Peters (USA)



From aph at redhat.com  Tue Apr 17 06:10:02 2012
From: aph at redhat.com (Andrew Haley)
Date: Tue, 17 Apr 2012 14:10:02 +0100
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its name should be openjdk-plugin !
In-Reply-To: <4F8D68FE.70503@redhat.com>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>	<4F8B0820.7050001@redhat.com>	<CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>	<87lilwsule.fsf@mid.deneb.enyo.de>	<CACGw4H4c+dYKtNFaP+UKJg3ZEtMp0RZGavGRMjvbms9PGJoErg@mail.gmail.com>	<87aa2cstbv.fsf@mid.deneb.enyo.de>	<CACGw4H5yWav9s92ttbEdJ2CGDf1TO_FW+MV2sefHOHgUvMr72A@mail.gmail.com>	<4F8BD917.9070500@redhat.com>
	<4F8BE44E.5070003@redhat.com>	<4F8BE6E4.7090609@redhat.com>	<CACGw4H4K+oyHR9jeLoqnsQbGCtSPig-FbpbdxY85FEiWyD01kg@mail.gmail.com>	<4F8BF674.4020809@redhat.com>	<CACGw4H6-e=67ZkdwDfj4S9fMNO5Ptb-rDi4hTmtO7W9O6FaFsA@mail.gmail.com>	<4F8D3AC7.1000305@redhat.com>
	<4F8D4AB3.5070909@redhat.com>	<CACGw4H7BmYzt9SZN6iJyfpsjAnQ4yDKuELELXFr-UM33SPmkXQ@mail.gmail.com>
	<4F8D6374.9010703@redhat.com> <4F8D68FE.70503@redhat.com>
Message-ID: <4F8D6BAA.9050000@redhat.com>

On 04/17/2012 01:58 PM, Pavel Tisnovsky wrote:
> Andrew Dinn wrote:
>> On 17/04/12 12:47, Fernando Cassia wrote:
>>> I just did a "yum install packagename*" on several packages in my server
>>> box running
>>> Fedora 17 (beta, rc3).
>>
>> Yes, you are correct -- I was misreading the error I got when I ran this
>> command
>>
>>   [root at sputstik ~]# yum install openjdk*
>>   Loaded plugins: langpacks, presto, refresh-packagekit
>>   Setting up Install Process
>>   No package openjdk* available.
>>   Error: Nothing to do
>>   [root at sputstik ~]#
>>
>> The problem is not the wildcard itself, rather that the pattern openjdk*
>> does not match an actual package. The following does work
>>
>>   [root at sputstik ~]# yum install *openjdk*
> 
> AFAIK it's still not 100% correct, because shell could in some circumstances
> expand *openjdk* into file list (depending on contents of `pwd` of course).
> Safer is to use "*openjdk*"

The core problem, I suppose, is that it's rather hard to know that you
need the name "java-1.x.0-openjdk", and the fact that "icedtea-web" is
independent is rather confusing.

Having said that, "yum search openjdk" does find

icedtea-web.x86_64 : Additional Java components for OpenJDK

...although the description sucks mightily.

Andrew.



From jvanek at redhat.com  Tue Apr 17 06:55:33 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Tue, 17 Apr 2012 15:55:33 +0200
Subject: [rfc][icedtea-web]encoding test
Message-ID: <4F8D7655.8070206@redhat.com>

Hi!

This is reproducer for incorrect behaviour of icedtea-web when jnlps are in "unexpected" encoding.
We are expecting utf-8 everywhere, but windows users can very easily expose jnlps in different one. 
And we should process them for unix user correctly.
I have used ISO-8859-2 encoding to torture icedtea-web.
All tests to this encoding have failed. I have added also set of UTF-8 tests above those cases, and 
all those are passing (so test should be correct).

Sorry that diff is not in classical patch format, but diff tools have not cooperate well with mixed 
utf8/non-utf8  content. And it is just adding files so "applying" should be simple as with patch.

Please note, that this adds 3 more passing and three more failing tests - which are representing the 
issue. Maybe annotation marking this "representatives" will become necessary soon?

The name of the directory is so weird  because I wanted to create resource containing those unhappy 
characters. (The engine creates nameOfDirectory.jar)

I'm going to check this also for applets, but here launching informations are provided by brpwser so 
it should be ok.

Changelog:
2012-04-17  Jiri Vanek  <jvanek at redhat.com>

	added encodings reproducer
	* tests/jnlp_tests/simple/encodingTests????????????????????????: new reproducer
	* tests/jnlp_tests/simple/encodingTests????????????????????????/srcs/encodingTest.java:
	main class and method of new encodingTests????????????????????????.jar
	* tests/jnlp_tests/simple/encodingTests????????????????????????/testcases/encodingTestTest.java:
	testcases for jnlps of this reproducers
	* tests/jnlp_tests/simple/encodingTests????????????????????????/resources:
	three utf-8 and three iso-8859-2 jnlp files


-------------- next part --------------
A non-text attachment was scrubbed...
Name: encodingsTest.tar.gz
Type: application/x-gzip
Size: 3283 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120417/1162bb88/encodingsTest.tar.gz 

From jgh at FreeBSD.org  Tue Apr 17 07:35:58 2012
From: jgh at FreeBSD.org (Jason Helfman)
Date: Tue, 17 Apr 2012 07:35:58 -0700
Subject: porting icedtea6 to FreeBSD
In-Reply-To: <7f930db0-bfbd-4a85-9f8e-8c357bfb710a@zmail17.collab.prod.int.phx2.redhat.com>
References: <20120417064043.GA17160@dormouse.experts-exchange.com>
	<7f930db0-bfbd-4a85-9f8e-8c357bfb710a@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <CAMuy=+jM4kWYJ+FpvEF8s=jo9LRmvgdW-1gAN9QQhFt0Xk4uEg@mail.gmail.com>

On Tue, Apr 17, 2012 at 4:51 AM, Andrew Hughes <ahughes at redhat.com> wrote:

> ----- Original Message -----
> > On Mon, Apr 16, 2012 at 09:59:00AM -0400, Andrew Hughes thus spake:
> > >> Any thoughts on any of this?
> > >> Thanks, again.
> > >>
> > >> -jgh
> > >
> > >What are you doing here?
> > >
> > >/usr/bin/sed -i.bak -e 's|--dry-run||g'
> >
> >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.am
> >
> >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.in
> > >/usr/bin/sed -i.bak -e 's|--check|-q|g'
> >
> >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.am
> >
> >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.in
> > >
> > >If you're removing --dry-run, you're going to be applying the patch
> > >twice, which is why it's failing.
> > >--
> > >Andrew :)
> >
> > I've modified this to test the patch which in FreeBSD is the "-C"
> > switch,
> > and the "-q" is for SHASUM's to only output the hash.
> >
> > I was able to get much further in the build! Any thoughts on why this
> > patch
> > was seen as already applied?
> >
>
> Because the build tests the patch, then applies it if that passes.  If you
> removed --dry-run from the first invocation and didn't replace it with -C,
> you'd be applying the patch twice instead.
>
>
That is what I have done, though. --dry-run is being replaced with -C in
the build.
Is something else showing up?

-jgh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120417/a27f55a3/attachment.html 

From jvanek at icedtea.classpath.org  Tue Apr 17 07:43:04 2012
From: jvanek at icedtea.classpath.org (jvanek at icedtea.classpath.org)
Date: Tue, 17 Apr 2012 14:43:04 +0000
Subject: /hg/icedtea-web: 2 new changesets
Message-ID: <hg.701690a5a270.1334673784.8643924302249223276@icedtea.classpath.org>

changeset 701690a5a270 in /hg/icedtea-web
details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=701690a5a270
author: Jiri Vanek <jvanek at redhat.com>
date: Tue Apr 17 16:41:09 2012 +0200

	Fixed xfork test with kill signal


changeset 2a13d6d1b57c in /hg/icedtea-web
details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=2a13d6d1b57c
author: Jiri Vanek <jvanek at redhat.com>
date: Tue Apr 17 16:43:11 2012 +0200

	minor typos fixes


diffstat:

 ChangeLog                                                            |    9 +
 tests/jnlp_tests/simple/deadlocktest/testcases/DeadLockTestTest.java |  118 +++++++--
 2 files changed, 96 insertions(+), 31 deletions(-)

diffs (215 lines):

diff -r 17f9e4e1ac6d -r 2a13d6d1b57c ChangeLog
--- a/ChangeLog	Wed Apr 11 10:19:17 2012 +0200
+++ b/ChangeLog	Tue Apr 17 16:43:11 2012 +0200
@@ -1,3 +1,12 @@
+2012-04-17  Jiri Vanek <jvanek at redhat.com>
+
+	Rewritten DeadLockTestTest to stop failing in more then 1/2 of cases
+	All assassinated processes were hanging as zombies, killed forcibly by
+	kill -9 now.
+	* /tests/jnlp_tests/simple/deadlocktest/testcases/DeadLockTestTest.java:
+	(countJavaInstances) now return pids of found javas.
+	(killDiff) new method killing zombie javas forcibly.
+
 2012-04-11  Jiri Vanek  <jvanek at redhat.com>
 
 	* Makefile.am: EMMA_JAVA_ARGS, new variable for adjusting emma runs. 
diff -r 17f9e4e1ac6d -r 2a13d6d1b57c tests/jnlp_tests/simple/deadlocktest/testcases/DeadLockTestTest.java
--- a/tests/jnlp_tests/simple/deadlocktest/testcases/DeadLockTestTest.java	Wed Apr 11 10:19:17 2012 +0200
+++ b/tests/jnlp_tests/simple/deadlocktest/testcases/DeadLockTestTest.java	Tue Apr 17 16:43:11 2012 +0200
@@ -35,6 +35,7 @@
 exception statement from your version.
  */
 
+import java.util.ArrayList;
 import net.sourceforge.jnlp.ServerAccess;
 import net.sourceforge.jnlp.ServerAccess.ProcessResult;
 import org.junit.Assert;
@@ -61,32 +62,38 @@
     @Test
     public void testDeadLockTestTerminated() throws Exception {
         testDeadLockTestTerminatedBody(deadlocktest);
-        System.out.println("Currently runnng javas2 " + countJavaInstances());
     }
 
     @Test
     public void testDeadLockTestTerminated2() throws Exception {
         testDeadLockTestTerminatedBody(deadlocktest_1);
-        System.out.println("Currently runnng javas3 " + countJavaInstances());
     }
 
     public void testDeadLockTestTerminatedBody(String jnlp) throws Exception {
+        List<String> before = countJavaInstances();
+        System.out.println("java1 "+jnlp+" : " + before.size());
         System.out.println("connecting " + jnlp + " request");
         System.err.println("connecting " + jnlp + " request");
         ServerAccess.ProcessResult pr = server.executeJavawsHeadless(null, jnlp);
         System.out.println(pr.stdout);
         System.err.println(pr.stderr);
         assertDeadlockTestLaunched(pr);
-        Assert.assertFalse(pr.stdout.contains("This process is hanging more then 30s. Should be killed"));
+        List<String> after = countJavaInstances();
+        System.out.println("java2 "+jnlp+" : " + after.size());
+        String ss="This process is hanging more than 30s. Should be killed";
+        Assert.assertFalse("stdout shoud not contains: "+ss+", but did",pr.stdout.contains(ss));
 //        Assert.assertTrue(pr.stderr.contains("xception"));, exception is thrown by engine,not by application
         Assert.assertTrue("testDeadLockTestTerminated should be terminated, but wasn't", pr.wasTerminated);
         Assert.assertEquals(null, pr.returnValue);//killed process have no value
+        killDiff(before, after);
+        List<String> afterKill = countJavaInstances();
+        System.out.println("java3 "+jnlp+" : " + afterKill.size());
+        Assert.assertEquals("assert that just old javas remians", 0, (before.size() - afterKill.size()));
     }
 
     @Test
     public void ensureAtLeasOneJavaIsRunning() throws Exception {
-        Assert.assertTrue("at least one java should be running, but isnt! Javas are probably counted badly", countJavaInstances() > 0);
-        ;
+        Assert.assertTrue("at least one java should be running, but isn't! Javas are probably counted badly", countJavaInstances().size() > 0);
 
     }
 
@@ -94,63 +101,105 @@
     public void testSimpletest1lunchFork() throws Exception {
         System.out.println("connecting " + deadlocktest_1 + " request");
         System.err.println("connecting " + deadlocktest_1 + " request");
-        int before = countJavaInstances();
-        System.out.println("java4: " + before);
+        List<String> before = countJavaInstances();
+        System.out.println("java4: " + before.size());
         BackgroundDeadlock bd = new BackgroundDeadlock(deadlocktest_1, null);
         bd.start();
         Thread.sleep(ServerAccess.PROCESS_TIMEOUT * 2 / 3);
-        int during = +countJavaInstances();
-        System.out.println("java5: " + during);
+        List<String> during = countJavaInstances();
+        System.out.println("java5: " + during.size());
         waitForBackgroundDeadlock(bd);
-        Thread.sleep(500);
-        int after = countJavaInstances();
-        System.out.println("java6: " + after);
-        Assert.assertNotNull("proces inside background deadlock cant be null. Was.", bd.getPr());
+        List<String> after = countJavaInstances();
+        System.out.println("java6: " + after.size());
+        Assert.assertNotNull("proces inside background deadlock cant be null. It was.", bd.getPr());
         System.out.println(bd.getPr().stdout);
         System.err.println(bd.getPr().stderr);
         assertDeadlockTestLaunched(bd.getPr());
-        Assert.assertEquals("lunched JVMs must be exactly 2, was " + (during - before), 2, during - before);
+        killDiff(before, during);
+        List<String> afterKill = countJavaInstances();
+        System.out.println("java66: " + afterKill.size());
+        Assert.assertEquals("assert that just old javas remians", 0, (before.size() - afterKill.size()));
+        // div by two is caused by jav in java process hierarchy
+        Assert.assertEquals("launched JVMs must be exactly 2, was " + (during.size() - before.size()) / 2, 2, (during.size() - before.size()) / 2);
     }
 
     @Test
     public void testSimpletest1lunchNoFork() throws Exception {
         System.out.println("connecting " + deadlocktest_1 + " Xnofork request");
         System.err.println("connecting " + deadlocktest_1 + " Xnofork request");
-        int before = countJavaInstances();
-        System.out.println("java7: " + before);
+        List<String> before = countJavaInstances();
+        System.out.println("java7: " + before.size());
         BackgroundDeadlock bd = new BackgroundDeadlock(deadlocktest_1, Arrays.asList(new String[]{"-Xnofork"}));
         bd.start();
         Thread.sleep(ServerAccess.PROCESS_TIMEOUT * 2 / 3);
-        int during = +countJavaInstances();
-        System.out.println("java8: " + during);
+        List<String> during = countJavaInstances();
+        System.out.println("java8: " + during.size());
         waitForBackgroundDeadlock(bd);
-        Thread.sleep(500);
-        int after = countJavaInstances();
-        System.out.println("java9: " + after);
-        Assert.assertNotNull("proces inside background deadlock cant be null. Was.", bd.getPr());
+        List<String> after = countJavaInstances();
+        System.out.println("java9: " + after.size());
+        Assert.assertNotNull("proces inside background deadlock cant be null. It was.", bd.getPr());
         System.out.println(bd.getPr().stdout);
         System.err.println(bd.getPr().stderr);
         assertDeadlockTestLaunched(bd.getPr());
-        Assert.assertEquals("lunched JVMs must be exactly 1, was  " + (during - before), 1, during - before);
-        ;
+        killDiff(before, during);
+        List<String> afterKill = countJavaInstances();
+        System.out.println("java99: " + afterKill.size());
+        Assert.assertEquals("assert that just old javas remians", 0, (before.size() - afterKill.size()));
+        // div by two is caused by jav in java process hierarchy
+        Assert.assertEquals("launched JVMs must be exactly 1, was  " + (during.size() - before.size()) / 2, 1, (during.size() - before.size()) / 2);
     }
 
-    private static int countJavaInstances() throws Exception {
-        String os = System.getProperty("os.name").toLowerCase();
-        if (!(os.contains("linux") || os.contains("unix"))) {
-            throw new IllegalStateException("This test can be procesed only on linux like machines");
+    /**
+     * by process assasin destroyed processes are hanging random amount of time as zombies.
+     * Kill -9 is handling zombies pretty well.
+     *
+     * This function kills or  processes which are in nw but are not in old
+     * (eq.to killing new zombies:) )
+     *
+     * @param old
+     * @param nw
+     * @return
+     * @throws Exception
+     */
+    private static List<String> killDiff(List<String> old, List<String> nw) throws Exception {
+        ensureLinux();
+        List<String> result = new ArrayList<String>();
+        for (String string : nw) {
+            if (old.contains(string)) {
+                continue;
+            }
+            System.out.println("Killing " + string);
+            ServerAccess.ProcessResult pr = ServerAccess.executeProcess(Arrays.asList(new String[]{"kill", "-9", string}));
+            result.add(string);
+            //System.out.println(pr.stdout);
+            // System.err.println(pr.stderr);
+            System.out.println("Killed " + string);
         }
-        ServerAccess.ProcessResult pr = ServerAccess.executeProcess(Arrays.asList(new String[]{"ps", "-A"}));
-        Matcher m = Pattern.compile("\\s+java\\s+").matcher(pr.stdout);
+        return result;
+    }
+
+    private static List<String> countJavaInstances() throws Exception {
+        ensureLinux();
+        List<String> result = new ArrayList<String>();
+        ServerAccess.ProcessResult pr = ServerAccess.executeProcess(Arrays.asList(new String[]{"ps", "-eo", "pid,ppid,stat,fname"}));
+        Matcher m = Pattern.compile("\\s*\\d+\\s+\\d+ .+ java\\s*").matcher(pr.stdout);
         //System.out.println(pr.stdout);
+        //System.err.println(pr.stderr);
         int i = 0;
         while (m.find()) {
             i++;
+            String ss = m.group();
+            //System.out.println(i+": "+ss);
+            result.add(ss.trim().split("\\s+")[0]);
         }
-        return i;
+        return result;
 
     }
 
+    public static void main(String[] args) throws Exception {
+        System.out.println(countJavaInstances());
+    }
+
     private void assertDeadlockTestLaunched(ProcessResult pr) {
         String s = "Deadlock test started";
         Assert.assertTrue("Deadlock test should print out " + s + ", but did not", pr.stdout.contains(s));
@@ -197,4 +246,11 @@
             return finished;
         }
     }
+
+    private static void ensureLinux() {
+        String os = System.getProperty("os.name").toLowerCase();
+        if (!(os.contains("linux") || os.contains("unix"))) {
+            throw new IllegalStateException("This test can be procesed only on linux like machines");
+        }
+    }
 }


From ahughes at redhat.com  Tue Apr 17 07:55:33 2012
From: ahughes at redhat.com (Andrew Hughes)
Date: Tue, 17 Apr 2012 10:55:33 -0400 (EDT)
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its name should be openjdk-plugin !
In-Reply-To: <4F8D6BAA.9050000@redhat.com>
Message-ID: <d57fac4e-dd51-4a78-a38b-4b2fae844ea7@zmail17.collab.prod.int.phx2.redhat.com>

----- Original Message -----
> On 04/17/2012 01:58 PM, Pavel Tisnovsky wrote:
> > Andrew Dinn wrote:
> >> On 17/04/12 12:47, Fernando Cassia wrote:
> >>> I just did a "yum install packagename*" on several packages in my
> >>> server
> >>> box running
> >>> Fedora 17 (beta, rc3).
> >>
> >> Yes, you are correct -- I was misreading the error I got when I
> >> ran this
> >> command
> >>
> >>   [root at sputstik ~]# yum install openjdk*
> >>   Loaded plugins: langpacks, presto, refresh-packagekit
> >>   Setting up Install Process
> >>   No package openjdk* available.
> >>   Error: Nothing to do
> >>   [root at sputstik ~]#
> >>
> >> The problem is not the wildcard itself, rather that the pattern
> >> openjdk*
> >> does not match an actual package. The following does work
> >>
> >>   [root at sputstik ~]# yum install *openjdk*
> > 
> > AFAIK it's still not 100% correct, because shell could in some
> > circumstances
> > expand *openjdk* into file list (depending on contents of `pwd` of
> > course).
> > Safer is to use "*openjdk*"
> 
> The core problem, I suppose, is that it's rather hard to know that
> you
> need the name "java-1.x.0-openjdk", and the fact that "icedtea-web"
> is
> independent is rather confusing.
> 
> Having said that, "yum search openjdk" does find
> 
> icedtea-web.x86_64 : Additional Java components for OpenJDK
> 
> ...although the description sucks mightily.
> 
> Andrew.
> 
> 

That is a very odd description.

I'd have thought something more like "Web browser plugin and Web Start implementation for OpenJDK" would
be better, but I guess there's a whole can of trademark worms with "Web Start" too :-(
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From ahughes at redhat.com  Tue Apr 17 07:56:11 2012
From: ahughes at redhat.com (Andrew Hughes)
Date: Tue, 17 Apr 2012 10:56:11 -0400 (EDT)
Subject: porting icedtea6 to FreeBSD
In-Reply-To: <CAMuy=+jM4kWYJ+FpvEF8s=jo9LRmvgdW-1gAN9QQhFt0Xk4uEg@mail.gmail.com>
Message-ID: <73684032-8d02-406f-8af2-e43e59f6c7dd@zmail17.collab.prod.int.phx2.redhat.com>

----- Original Message -----
> 
> 
> 
> On Tue, Apr 17, 2012 at 4:51 AM, Andrew Hughes < ahughes at redhat.com >
> wrote:
> 
> 
> 
> ----- Original Message -----
> > On Mon, Apr 16, 2012 at 09:59:00AM -0400, Andrew Hughes thus spake:
> > >> Any thoughts on any of this?
> > >> Thanks, again.
> > >> 
> > >> -jgh
> > > 
> > >What are you doing here?
> > > 
> > >/usr/bin/sed -i.bak -e 's|--dry-run||g'
> > >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.am
> > >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.in
> > >/usr/bin/sed -i.bak -e 's|--check|-q|g'
> > >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.am
> > >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.in
> > > 
> > >If you're removing --dry-run, you're going to be applying the
> > >patch
> > >twice, which is why it's failing.
> > >--
> > >Andrew :)
> > 
> > I've modified this to test the patch which in FreeBSD is the "-C"
> > switch,
> > and the "-q" is for SHASUM's to only output the hash.
> > 
> > I was able to get much further in the build! Any thoughts on why
> > this
> > patch
> > was seen as already applied?
> > 
> 
> Because the build tests the patch, then applies it if that passes. If
> you
> removed --dry-run from the first invocation and didn't replace it
> with -C,
> you'd be applying the patch twice instead.
> 
> 
> 
> That is what I have done, though. --dry-run is being replaced with -C
> in the build.
> Is something else showing up?
> 
> -jgh
> 
> 

And it's still failing in the same way?  I thought you said you'd got much further... :-S
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From jgh at FreeBSD.org  Tue Apr 17 08:08:43 2012
From: jgh at FreeBSD.org (Jason Helfman)
Date: Tue, 17 Apr 2012 08:08:43 -0700
Subject: porting icedtea6 to FreeBSD
In-Reply-To: <73684032-8d02-406f-8af2-e43e59f6c7dd@zmail17.collab.prod.int.phx2.redhat.com>
References: <CAMuy=+jM4kWYJ+FpvEF8s=jo9LRmvgdW-1gAN9QQhFt0Xk4uEg@mail.gmail.com>
	<73684032-8d02-406f-8af2-e43e59f6c7dd@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <CAMuy=+gA8o6khgtA3U3BZ_Ug=E9XSO2rr9m2w2qTqAR2OQES_A@mail.gmail.com>

On Tue, Apr 17, 2012 at 7:56 AM, Andrew Hughes <ahughes at redhat.com> wrote:

> ----- Original Message -----
> >
> >
> >
> > On Tue, Apr 17, 2012 at 4:51 AM, Andrew Hughes < ahughes at redhat.com >
> > wrote:
> >
> >
> >
> > ----- Original Message -----
> > > On Mon, Apr 16, 2012 at 09:59:00AM -0400, Andrew Hughes thus spake:
> > > >> Any thoughts on any of this?
> > > >> Thanks, again.
> > > >>
> > > >> -jgh
> > > >
> > > >What are you doing here?
> > > >
> > > >/usr/bin/sed -i.bak -e 's|--dry-run||g'
> > >
> >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.am
> > >
> >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.in
> > > >/usr/bin/sed -i.bak -e 's|--check|-q|g'
> > >
> >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.am
> > >
> >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.in
> > > >
> > > >If you're removing --dry-run, you're going to be applying the
> > > >patch
> > > >twice, which is why it's failing.
> > > >--
> > > >Andrew :)
> > >
> > > I've modified this to test the patch which in FreeBSD is the "-C"
> > > switch,
> > > and the "-q" is for SHASUM's to only output the hash.
> > >
> > > I was able to get much further in the build! Any thoughts on why
> > > this
> > > patch
> > > was seen as already applied?
> > >
> >
> > Because the build tests the patch, then applies it if that passes. If
> > you
> > removed --dry-run from the first invocation and didn't replace it
> > with -C,
> > you'd be applying the patch twice instead.
> >
> >
> >
> > That is what I have done, though. --dry-run is being replaced with -C
> > in the build.
> > Is something else showing up?
> >
> > -jgh
> >
> >
>
> And it's still failing in the same way?  I thought you said you'd got much
> further... :-S
> --
> Andrew :)
>

Yes, it is failing in the same way but much further into the build.
Initially, it would fail at the first/second patch.
I attached the latest buildlog to my email last night. It should show the
issue, and with what patch the problem
was with.

-jgh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120417/29705f49/attachment.html 

From dbhole at redhat.com  Tue Apr 17 08:54:12 2012
From: dbhole at redhat.com (Deepak Bhole)
Date: Tue, 17 Apr 2012 11:54:12 -0400
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its name should be openjdk-plugin !
In-Reply-To: <4F8D6BAA.9050000@redhat.com>
References: <4F8BE6E4.7090609@redhat.com>
	<CACGw4H4K+oyHR9jeLoqnsQbGCtSPig-FbpbdxY85FEiWyD01kg@mail.gmail.com>
	<4F8BF674.4020809@redhat.com>
	<CACGw4H6-e=67ZkdwDfj4S9fMNO5Ptb-rDi4hTmtO7W9O6FaFsA@mail.gmail.com>
	<4F8D3AC7.1000305@redhat.com> <4F8D4AB3.5070909@redhat.com>
	<CACGw4H7BmYzt9SZN6iJyfpsjAnQ4yDKuELELXFr-UM33SPmkXQ@mail.gmail.com>
	<4F8D6374.9010703@redhat.com> <4F8D68FE.70503@redhat.com>
	<4F8D6BAA.9050000@redhat.com>
Message-ID: <20120417155411.GI14177@redhat.com>

* Andrew Haley <aph at redhat.com> [2012-04-17 09:11]:
> On 04/17/2012 01:58 PM, Pavel Tisnovsky wrote:
> > Andrew Dinn wrote:
> >> On 17/04/12 12:47, Fernando Cassia wrote:
> >>> I just did a "yum install packagename*" on several packages in my server
> >>> box running
> >>> Fedora 17 (beta, rc3).
> >>
> >> Yes, you are correct -- I was misreading the error I got when I ran this
> >> command
> >>
> >>   [root at sputstik ~]# yum install openjdk*
> >>   Loaded plugins: langpacks, presto, refresh-packagekit
> >>   Setting up Install Process
> >>   No package openjdk* available.
> >>   Error: Nothing to do
> >>   [root at sputstik ~]#
> >>
> >> The problem is not the wildcard itself, rather that the pattern openjdk*
> >> does not match an actual package. The following does work
> >>
> >>   [root at sputstik ~]# yum install *openjdk*
> > 
> > AFAIK it's still not 100% correct, because shell could in some circumstances
> > expand *openjdk* into file list (depending on contents of `pwd` of course).
> > Safer is to use "*openjdk*"
> 
> The core problem, I suppose, is that it's rather hard to know that you
> need the name "java-1.x.0-openjdk", and the fact that "icedtea-web" is
> independent is rather confusing.
> 

icedtea-web does virtual provide java-1.x.0-openjdk-plugin. Yum install
java-1.6.0-openjdk-plugin should work on F15 and F16. For F17, it should
be java-1.7.0-openjdk-plugin, but there was a bug in the spec. I just
fixed it and it is rebuilding now.

yum install java-1.x.0-openjdk* will *not* install icedtea-web however.
But that seems like a bug in yum to me as there is nothing that the spec
file can do about it.

> Having said that, "yum search openjdk" does find
> 
> icedtea-web.x86_64 : Additional Java components for OpenJDK
> 
> ...although the description sucks mightily.

Originally wanted to have the plug-in and javaws as separate
packages so the summary was kept generic for the parent package.

I have fixed it and new builds are happening now:
http://koji.fedoraproject.org/koji/buildinfo?buildID=313780
http://koji.fedoraproject.org/koji/buildinfo?buildID=313784
http://koji.fedoraproject.org/koji/buildinfo?buildID=313779

It now says:
"Java browser plug-in and Web Start implementation"

Cheers,
Deepak


From ptisnovs at icedtea.classpath.org  Tue Apr 17 08:57:29 2012
From: ptisnovs at icedtea.classpath.org (ptisnovs at icedtea.classpath.org)
Date: Tue, 17 Apr 2012 15:57:29 +0000
Subject: /hg/release/icedtea6-1.10: PR881: Sign tests (wsse.policy.basic)...
Message-ID: <hg.182bdaba43ea.1334678249.-53431993501496596@icedtea.classpath.org>

changeset 182bdaba43ea in /hg/release/icedtea6-1.10
details: http://icedtea.classpath.org/hg/release/icedtea6-1.10?cmd=changeset;node=182bdaba43ea
author: ptisnovs
date: Tue Apr 17 18:57:20 2012 +0200

	PR881: Sign tests (wsse.policy.basic) failures with OpenJDK6


diffstat:

 ChangeLog                    |    7 +
 Makefile.am                  |    3 +-
 NEWS                         |    1 +
 patches/idresolver_fix.patch |  193 +++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 203 insertions(+), 1 deletions(-)

diffs (236 lines):

diff -r 7b2da3e832e1 -r 182bdaba43ea ChangeLog
--- a/ChangeLog	Fri Mar 09 13:48:15 2012 -0500
+++ b/ChangeLog	Tue Apr 17 18:57:20 2012 +0200
@@ -1,3 +1,10 @@
+2012-04-17  Pavel Tisnovsky  <ptisnovs at redhat.com>
+
+	PR881: Sign tests (wsse.policy.basic) failures with OpenJDK6
+	* Makefile.am: Updated
+	* patches/idresolver_fix.patch: added patch for a class
+	IdResolver.
+
 2012-03-09  Danesh Dadachanji  <ddadacha at redhat.com>
 
 	* Makefile.am:
diff -r 7b2da3e832e1 -r 182bdaba43ea Makefile.am
--- a/Makefile.am	Fri Mar 09 13:48:15 2012 -0500
+++ b/Makefile.am	Tue Apr 17 18:57:20 2012 +0200
@@ -379,7 +379,8 @@
 	patches/openjdk/7102369-7094468-rmiregistry.patch \
 	patches/openjdk/7103725-ssl_beast_regression.patch \
 	patches/openjdk/6851973-kerberos.patch \
-	patches/openjdk/7091528-javadoc_class_files.patch
+	patches/openjdk/7091528-javadoc_class_files.patch \
+	patches/idresolver_fix.patch
 
 if WITH_ALT_HSBUILD
 ICEDTEA_PATCHES += \
diff -r 7b2da3e832e1 -r 182bdaba43ea NEWS
--- a/NEWS	Fri Mar 09 13:48:15 2012 -0500
+++ b/NEWS	Tue Apr 17 18:57:20 2012 +0200
@@ -12,6 +12,7 @@
 New in release 1.10.7 (2012-XX-XX):
 * Bug fixes
   - PR732: Use xsltproc for bootstrap xslt in place of Xerces/Xalan
+  - PR881: Sign tests (wsse.policy.basic) failures with OpenJDK6
 
 New in release 1.10.6 (2012-02-14):
 
diff -r 7b2da3e832e1 -r 182bdaba43ea patches/idresolver_fix.patch
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/patches/idresolver_fix.patch	Tue Apr 17 18:57:20 2012 +0200
@@ -0,0 +1,194 @@
+--- openjdk/jdk/src/share/classes/com/sun/org/apache/xml/internal/security/utils/IdResolver.java	2012-03-20 20:29:30.000000000 +0100
++++ openjdk/jdk/src/share/classes/com/sun/org/apache/xml/internal/security/utils/IdResolver.java	2012-03-20 22:18:41.094309861 +0100
+@@ -26,6 +26,7 @@
+ import org.w3c.dom.Attr;
+ import org.w3c.dom.Document;
+ import org.w3c.dom.Element;
++import org.w3c.dom.NamedNodeMap;
+ import org.w3c.dom.Node;
+ 
+ import java.util.Arrays;
+@@ -175,69 +176,124 @@
+        return null;
+    }
+ 
++    private static java.util.List names;
++    private static int namesLength;
++    static {
++        String namespaces[]={
++            Constants.SignatureSpecNS,
++            EncryptionConstants.EncryptionSpecNS,
++            "http://schemas.xmlsoap.org/soap/security/2000-12",
++            "http://www.w3.org/2002/03/xkms#",
++            "urn:oasis:names:tc:SAML:1.0:assertion",
++            "urn:oasis:names:tc:SAML:1.0:protocol"
++        };
++        names = Arrays.asList(namespaces);
++        namesLength = names.size();
++    }
+ 
+-   static java.util.List names;
+-   static {
+-           String namespaces[]={ Constants.SignatureSpecNS,
+-                           EncryptionConstants.EncryptionSpecNS,
+-                           "http://schemas.xmlsoap.org/soap/security/2000-12",
+-                           "http://www.w3.org/2002/03/xkms#"
+-                   };
+-           names=Arrays.asList(namespaces);
+-   }
+ 
++    private static Element getElementBySearching(Node root,String id) {
++            Element []els=new Element[namesLength + 1];
++            getEl(root,id,els);
++            for (int i=0;i<els.length;i++) {
++                    if (els[i]!=null) {
++                            return els[i];
++                    }
++            }
++            return null;
++    }
+ 
+-   private static Element getElementBySearching(Node root,String id) {
+-           Element []els=new Element[5];
+-           getElementBySearching(root,id,els);
+-           for (int i=0;i<els.length;i++) {
+-                   if (els[i]!=null) {
+-                           return els[i];
+-                   }
+-           }
+-           return null;
++    private static int getEl(Node currentNode,String id,Element []els) {
++        Node sibling=null;
++        Node parentNode=null;
++        do {
++                switch (currentNode.getNodeType()) {
++                case Node.DOCUMENT_FRAGMENT_NODE :
++                case Node.DOCUMENT_NODE :
++                        sibling= currentNode.getFirstChild();
++                        break;
++
++
++                case Node.ELEMENT_NODE :
++                        Element currentElement = (Element) currentNode;
++                        if (isElement(currentElement, id, els)==1)
++                                return 1;
++                        sibling= currentNode.getFirstChild();
++                        if (sibling==null) {
++                            if (parentNode != null) {
++                                        sibling= currentNode.getNextSibling();
++                                    }
++                        } else {
++                                parentNode=currentElement;
++                        }
++                        break;
++        } while (sibling==null  && parentNode!=null) {
++                        sibling=parentNode.getNextSibling();
++                        parentNode=parentNode.getParentNode();
++                        if (!(parentNode instanceof Element)) {
++                                parentNode=null;
++                        }
++                }
++                if (sibling==null)
++                        return 1;
++                currentNode=sibling;
++                sibling=currentNode.getNextSibling();
++        } while(true);
+ 
+-   }
+-   private static int getElementBySearching(Node root,String id,Element []els) {
+-           switch (root.getNodeType()) {
+-           case Node.ELEMENT_NODE:
+-                   Element el=(Element)root;
+-                   if (el.hasAttributes()) {
+-                           int index=names.indexOf(el.getNamespaceURI());
+-                           if (index<0) {
+-                                   index=4;
+-                           }
+-                           if (el.getAttribute("Id").equals(id)) {
+-                                   els[index]=el;
+-                                   if (index==0) {
+-                                           return 1;
+-                                   }
+-                           } else if ( el.getAttribute("id").equals(id) ) {
+-                                   if (index!=2) {
+-                                           index=4;
+-                                   }
+-                                   els[index]=el;
+-                           } else if ( el.getAttribute("ID").equals(id) ) {
+-                                   if (index!=3) {
+-                                           index=4;
+-                                   }
+-                                   els[index]=el;
+-                           } else if ((index==3)&&(
+-                                   el.getAttribute("OriginalRequestID").equals(id) ||
+-                                   el.getAttribute("RequestID").equals(id) ||
+-                                   el.getAttribute("ResponseID" ).equals(id))) {
+-                                   els[3]=el;
+-                           }
+-                   }
+-                case Node.DOCUMENT_NODE:
+-                        Node sibling=root.getFirstChild();
+-                        while (sibling!=null) {
+-                                if (getElementBySearching(sibling,id,els)==1)
++    }
++    private static int isElement(Element el, String id,Element[] els) {
++        if (!el.hasAttributes()) {
++                return 0;
++        }
++        NamedNodeMap ns=el.getAttributes();
++        int elementIndex=names.indexOf(el.getNamespaceURI());
++            elementIndex=(elementIndex<0) ? namesLength : elementIndex;
++        for (int length=ns.getLength(), i=0; i<length; i++) {
++                Attr n=(Attr)ns.item(i);
++                String s=n.getNamespaceURI();
++
++                    int index=s==null ? elementIndex : names.indexOf(n.getNamespaceURI());
++                    index=(index<0) ? namesLength : index;
++                    String name=n.getLocalName();
++                    if (name == null)
++                        name = n.getName();
++                    if (name.length()>2)
++                        continue;
++                    String value=n.getNodeValue();
++                    if (name.charAt(0)=='I') {
++                        char ch=name.charAt(1);
++                        if (ch=='d' && value.equals(id)) {
++                                els[index]=el;
++                                if (index==0) {
+                                         return 1;
+-                                sibling=sibling.getNextSibling();
++                                }
++                        } else if (ch=='D' &&value.endsWith(id)) {
++                                if (index!=3) {
++                                    index=namesLength;
++                                }
++                                els[index]=el;
+                         }
+-           }
+-           return 0;
+-   }
+-
++                    } else if ( "id".equals(name) && value.equals(id) ) {
++                        if (index!=2) {
++                                index=namesLength;
++                        }
++                        els[index]=el;
++                    }
++        }
++        //For an element namespace search for importants
++        if ((elementIndex==3)&&(
++                    el.getAttribute("OriginalRequestID").equals(id) ||
++                    el.getAttribute("RequestID").equals(id) ||
++                    el.getAttribute("ResponseID").equals(id))) {
++                    els[3]=el;
++        } else if ((elementIndex==4)&&(
++                    el.getAttribute("AssertionID").equals(id))) {
++                    els[4]=el;
++        } else if ((elementIndex==5)&&(
++                    el.getAttribute("RequestID").equals(id) ||
++                    el.getAttribute("ResponseID").equals(id))) {
++                    els[5]=el;
++                 }
++        return 0;
++    }
+ }


From ptisnovs at icedtea.classpath.org  Tue Apr 17 09:01:02 2012
From: ptisnovs at icedtea.classpath.org (ptisnovs at icedtea.classpath.org)
Date: Tue, 17 Apr 2012 16:01:02 +0000
Subject: /hg/release/icedtea6-1.11: PR881: Sign tests (wsse.policy.basic)...
Message-ID: <hg.16896bd9ecbc.1334678462.-53431993501496595@icedtea.classpath.org>

changeset 16896bd9ecbc in /hg/release/icedtea6-1.11
details: http://icedtea.classpath.org/hg/release/icedtea6-1.11?cmd=changeset;node=16896bd9ecbc
author: ptisnovs
date: Tue Apr 17 19:00:05 2012 +0200

	PR881: Sign tests (wsse.policy.basic) failures with OpenJDK6


diffstat:

 ChangeLog                    |    7 +
 Makefile.am                  |    3 +-
 NEWS                         |    1 +
 patches/idresolver_fix.patch |  193 +++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 203 insertions(+), 1 deletions(-)

diffs (236 lines):

diff -r a134afa67a3f -r 16896bd9ecbc ChangeLog
--- a/ChangeLog	Thu Mar 29 18:28:28 2012 +0200
+++ b/ChangeLog	Tue Apr 17 19:00:05 2012 +0200
@@ -1,3 +1,10 @@
+2012-04-17  Pavel Tisnovsky  <ptisnovs at redhat.com>
+
+	PR881: Sign tests (wsse.policy.basic) failures with OpenJDK6
+	* Makefile.am: Updated
+	* patches/idresolver_fix.patch: added patch for a class
+	IdResolver.
+
 2012-03-29  Pavel Tisnovsky  <ptisnovs at redhat.com>
 
 	* patches/revert-6885123.patch: Removed to fix
diff -r a134afa67a3f -r 16896bd9ecbc Makefile.am
--- a/Makefile.am	Thu Mar 29 18:28:28 2012 +0200
+++ b/Makefile.am	Tue Apr 17 19:00:05 2012 +0200
@@ -416,7 +416,8 @@
 	patches/openjdk/7091528-javadoc_class_files.patch \
 	patches/openjdk/7103725-ssl_beast_regression.patch \
 	patches/openjdk/7140882-dont-return-booleans-from-methods-returning-pointers.patch \
-	patches/openjdk/remove-mimpure-option-to-gcc.patch
+	patches/openjdk/remove-mimpure-option-to-gcc.patch \
+	patches/idresolver_fix.patch
 
 if WITH_RHINO
 ICEDTEA_PATCHES += \
diff -r a134afa67a3f -r 16896bd9ecbc NEWS
--- a/NEWS	Thu Mar 29 18:28:28 2012 +0200
+++ b/NEWS	Tue Apr 17 19:00:05 2012 +0200
@@ -14,6 +14,7 @@
 
 * Bug fixes
   - RH789154: javac error messages no longer contain the full path to the offending file:
+  - PR881: Sign tests (wsse.policy.basic) failures with OpenJDK6
 
 New in release 1.11.1 (2012-02-14):
 
diff -r a134afa67a3f -r 16896bd9ecbc patches/idresolver_fix.patch
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/patches/idresolver_fix.patch	Tue Apr 17 19:00:05 2012 +0200
@@ -0,0 +1,194 @@
+--- openjdk/jdk/src/share/classes/com/sun/org/apache/xml/internal/security/utils/IdResolver.java	2012-03-20 20:29:30.000000000 +0100
++++ openjdk/jdk/src/share/classes/com/sun/org/apache/xml/internal/security/utils/IdResolver.java	2012-03-20 22:18:41.094309861 +0100
+@@ -26,6 +26,7 @@
+ import org.w3c.dom.Attr;
+ import org.w3c.dom.Document;
+ import org.w3c.dom.Element;
++import org.w3c.dom.NamedNodeMap;
+ import org.w3c.dom.Node;
+ 
+ import java.util.Arrays;
+@@ -175,69 +176,124 @@
+        return null;
+    }
+ 
++    private static java.util.List names;
++    private static int namesLength;
++    static {
++        String namespaces[]={
++            Constants.SignatureSpecNS,
++            EncryptionConstants.EncryptionSpecNS,
++            "http://schemas.xmlsoap.org/soap/security/2000-12",
++            "http://www.w3.org/2002/03/xkms#",
++            "urn:oasis:names:tc:SAML:1.0:assertion",
++            "urn:oasis:names:tc:SAML:1.0:protocol"
++        };
++        names = Arrays.asList(namespaces);
++        namesLength = names.size();
++    }
+ 
+-   static java.util.List names;
+-   static {
+-           String namespaces[]={ Constants.SignatureSpecNS,
+-                           EncryptionConstants.EncryptionSpecNS,
+-                           "http://schemas.xmlsoap.org/soap/security/2000-12",
+-                           "http://www.w3.org/2002/03/xkms#"
+-                   };
+-           names=Arrays.asList(namespaces);
+-   }
+ 
++    private static Element getElementBySearching(Node root,String id) {
++            Element []els=new Element[namesLength + 1];
++            getEl(root,id,els);
++            for (int i=0;i<els.length;i++) {
++                    if (els[i]!=null) {
++                            return els[i];
++                    }
++            }
++            return null;
++    }
+ 
+-   private static Element getElementBySearching(Node root,String id) {
+-           Element []els=new Element[5];
+-           getElementBySearching(root,id,els);
+-           for (int i=0;i<els.length;i++) {
+-                   if (els[i]!=null) {
+-                           return els[i];
+-                   }
+-           }
+-           return null;
++    private static int getEl(Node currentNode,String id,Element []els) {
++        Node sibling=null;
++        Node parentNode=null;
++        do {
++                switch (currentNode.getNodeType()) {
++                case Node.DOCUMENT_FRAGMENT_NODE :
++                case Node.DOCUMENT_NODE :
++                        sibling= currentNode.getFirstChild();
++                        break;
++
++
++                case Node.ELEMENT_NODE :
++                        Element currentElement = (Element) currentNode;
++                        if (isElement(currentElement, id, els)==1)
++                                return 1;
++                        sibling= currentNode.getFirstChild();
++                        if (sibling==null) {
++                            if (parentNode != null) {
++                                        sibling= currentNode.getNextSibling();
++                                    }
++                        } else {
++                                parentNode=currentElement;
++                        }
++                        break;
++        } while (sibling==null  && parentNode!=null) {
++                        sibling=parentNode.getNextSibling();
++                        parentNode=parentNode.getParentNode();
++                        if (!(parentNode instanceof Element)) {
++                                parentNode=null;
++                        }
++                }
++                if (sibling==null)
++                        return 1;
++                currentNode=sibling;
++                sibling=currentNode.getNextSibling();
++        } while(true);
+ 
+-   }
+-   private static int getElementBySearching(Node root,String id,Element []els) {
+-           switch (root.getNodeType()) {
+-           case Node.ELEMENT_NODE:
+-                   Element el=(Element)root;
+-                   if (el.hasAttributes()) {
+-                           int index=names.indexOf(el.getNamespaceURI());
+-                           if (index<0) {
+-                                   index=4;
+-                           }
+-                           if (el.getAttribute("Id").equals(id)) {
+-                                   els[index]=el;
+-                                   if (index==0) {
+-                                           return 1;
+-                                   }
+-                           } else if ( el.getAttribute("id").equals(id) ) {
+-                                   if (index!=2) {
+-                                           index=4;
+-                                   }
+-                                   els[index]=el;
+-                           } else if ( el.getAttribute("ID").equals(id) ) {
+-                                   if (index!=3) {
+-                                           index=4;
+-                                   }
+-                                   els[index]=el;
+-                           } else if ((index==3)&&(
+-                                   el.getAttribute("OriginalRequestID").equals(id) ||
+-                                   el.getAttribute("RequestID").equals(id) ||
+-                                   el.getAttribute("ResponseID" ).equals(id))) {
+-                                   els[3]=el;
+-                           }
+-                   }
+-                case Node.DOCUMENT_NODE:
+-                        Node sibling=root.getFirstChild();
+-                        while (sibling!=null) {
+-                                if (getElementBySearching(sibling,id,els)==1)
++    }
++    private static int isElement(Element el, String id,Element[] els) {
++        if (!el.hasAttributes()) {
++                return 0;
++        }
++        NamedNodeMap ns=el.getAttributes();
++        int elementIndex=names.indexOf(el.getNamespaceURI());
++            elementIndex=(elementIndex<0) ? namesLength : elementIndex;
++        for (int length=ns.getLength(), i=0; i<length; i++) {
++                Attr n=(Attr)ns.item(i);
++                String s=n.getNamespaceURI();
++
++                    int index=s==null ? elementIndex : names.indexOf(n.getNamespaceURI());
++                    index=(index<0) ? namesLength : index;
++                    String name=n.getLocalName();
++                    if (name == null)
++                        name = n.getName();
++                    if (name.length()>2)
++                        continue;
++                    String value=n.getNodeValue();
++                    if (name.charAt(0)=='I') {
++                        char ch=name.charAt(1);
++                        if (ch=='d' && value.equals(id)) {
++                                els[index]=el;
++                                if (index==0) {
+                                         return 1;
+-                                sibling=sibling.getNextSibling();
++                                }
++                        } else if (ch=='D' &&value.endsWith(id)) {
++                                if (index!=3) {
++                                    index=namesLength;
++                                }
++                                els[index]=el;
+                         }
+-           }
+-           return 0;
+-   }
+-
++                    } else if ( "id".equals(name) && value.equals(id) ) {
++                        if (index!=2) {
++                                index=namesLength;
++                        }
++                        els[index]=el;
++                    }
++        }
++        //For an element namespace search for importants
++        if ((elementIndex==3)&&(
++                    el.getAttribute("OriginalRequestID").equals(id) ||
++                    el.getAttribute("RequestID").equals(id) ||
++                    el.getAttribute("ResponseID").equals(id))) {
++                    els[3]=el;
++        } else if ((elementIndex==4)&&(
++                    el.getAttribute("AssertionID").equals(id))) {
++                    els[4]=el;
++        } else if ((elementIndex==5)&&(
++                    el.getAttribute("RequestID").equals(id) ||
++                    el.getAttribute("ResponseID").equals(id))) {
++                    els[5]=el;
++                 }
++        return 0;
++    }
+ }


From omajid at redhat.com  Tue Apr 17 10:38:06 2012
From: omajid at redhat.com (Omair Majid)
Date: Tue, 17 Apr 2012 13:38:06 -0400
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its name should be openjdk-plugin !
In-Reply-To: <20120417155411.GI14177@redhat.com>
References: <4F8BE6E4.7090609@redhat.com>
	<CACGw4H4K+oyHR9jeLoqnsQbGCtSPig-FbpbdxY85FEiWyD01kg@mail.gmail.com>
	<4F8BF674.4020809@redhat.com>
	<CACGw4H6-e=67ZkdwDfj4S9fMNO5Ptb-rDi4hTmtO7W9O6FaFsA@mail.gmail.com>
	<4F8D3AC7.1000305@redhat.com> <4F8D4AB3.5070909@redhat.com>
	<CACGw4H7BmYzt9SZN6iJyfpsjAnQ4yDKuELELXFr-UM33SPmkXQ@mail.gmail.com>
	<4F8D6374.9010703@redhat.com> <4F8D68FE.70503@redhat.com>
	<4F8D6BAA.9050000@redhat.com> <20120417155411.GI14177@redhat.com>
Message-ID: <4F8DAA7E.908@redhat.com>

On 04/17/2012 11:54 AM, Deepak Bhole wrote:
>> The core problem, I suppose, is that it's rather hard to know that you
>> need the name "java-1.x.0-openjdk", and the fact that "icedtea-web" is
>> independent is rather confusing.
>>
> 
> icedtea-web does virtual provide java-1.x.0-openjdk-plugin. Yum install
> java-1.6.0-openjdk-plugin should work on F15 and F16. For F17, it should
> be java-1.7.0-openjdk-plugin, but there was a bug in the spec. I just
> fixed it and it is rebuilding now.
> 
> yum install java-1.x.0-openjdk* will *not* install icedtea-web however.
> But that seems like a bug in yum to me as there is nothing that the spec
> file can do about it.
> 

A possible "fix" would be for icedtea-web (or java-1.x.0-openjdk) to
generate an empty java-1.x.0-openjdk-plugin package that requires
icedtea-web.

>> Having said that, "yum search openjdk" does find
>>
>> icedtea-web.x86_64 : Additional Java components for OpenJDK
>>
>> ...although the description sucks mightily.
> 
> Originally wanted to have the plug-in and javaws as separate
> packages so the summary was kept generic for the parent package.
> 
> I have fixed it and new builds are happening now:
> http://koji.fedoraproject.org/koji/buildinfo?buildID=313780
> http://koji.fedoraproject.org/koji/buildinfo?buildID=313784
> http://koji.fedoraproject.org/koji/buildinfo?buildID=313779
> 
> It now says:
> "Java browser plug-in and Web Start implementation"

Thanks for taking care of it!

Cheers,
Omair


From dbhole at redhat.com  Tue Apr 17 10:40:47 2012
From: dbhole at redhat.com (Deepak Bhole)
Date: Tue, 17 Apr 2012 13:40:47 -0400
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its name should be openjdk-plugin !
In-Reply-To: <4F8DAA7E.908@redhat.com>
References: <4F8BF674.4020809@redhat.com>
	<CACGw4H6-e=67ZkdwDfj4S9fMNO5Ptb-rDi4hTmtO7W9O6FaFsA@mail.gmail.com>
	<4F8D3AC7.1000305@redhat.com> <4F8D4AB3.5070909@redhat.com>
	<CACGw4H7BmYzt9SZN6iJyfpsjAnQ4yDKuELELXFr-UM33SPmkXQ@mail.gmail.com>
	<4F8D6374.9010703@redhat.com> <4F8D68FE.70503@redhat.com>
	<4F8D6BAA.9050000@redhat.com> <20120417155411.GI14177@redhat.com>
	<4F8DAA7E.908@redhat.com>
Message-ID: <20120417174046.GM14177@redhat.com>

* Omair Majid <omajid at redhat.com> [2012-04-17 13:38]:
> On 04/17/2012 11:54 AM, Deepak Bhole wrote:
> >> The core problem, I suppose, is that it's rather hard to know that you
> >> need the name "java-1.x.0-openjdk", and the fact that "icedtea-web" is
> >> independent is rather confusing.
> >>
> > 
> > icedtea-web does virtual provide java-1.x.0-openjdk-plugin. Yum install
> > java-1.6.0-openjdk-plugin should work on F15 and F16. For F17, it should
> > be java-1.7.0-openjdk-plugin, but there was a bug in the spec. I just
> > fixed it and it is rebuilding now.
> > 
> > yum install java-1.x.0-openjdk* will *not* install icedtea-web however.
> > But that seems like a bug in yum to me as there is nothing that the spec
> > file can do about it.
> > 
> 
> A possible "fix" would be for icedtea-web (or java-1.x.0-openjdk) to
> generate an empty java-1.x.0-openjdk-plugin package that requires
> icedtea-web.
> 

We generally avoid creating meta packages for such purposes.
meta-packages are usually used when multiple packages want to be pulled
in at once (i.e. same use case as for yum groups).

Besides, this sounds a lot like a yum bug to me.

Cheers,
Deepak

> >> Having said that, "yum search openjdk" does find
> >>
> >> icedtea-web.x86_64 : Additional Java components for OpenJDK
> >>
> >> ...although the description sucks mightily.
> > 
> > Originally wanted to have the plug-in and javaws as separate
> > packages so the summary was kept generic for the parent package.
> > 
> > I have fixed it and new builds are happening now:
> > http://koji.fedoraproject.org/koji/buildinfo?buildID=313780
> > http://koji.fedoraproject.org/koji/buildinfo?buildID=313784
> > http://koji.fedoraproject.org/koji/buildinfo?buildID=313779
> > 
> > It now says:
> > "Java browser plug-in and Web Start implementation"
> 
> Thanks for taking care of it!
> 
> Cheers,
> Omair


From aph at redhat.com  Tue Apr 17 10:55:11 2012
From: aph at redhat.com (Andrew Haley)
Date: Tue, 17 Apr 2012 18:55:11 +0100
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its name should be openjdk-plugin !
In-Reply-To: <20120417174046.GM14177@redhat.com>
References: <4F8BF674.4020809@redhat.com>
	<CACGw4H6-e=67ZkdwDfj4S9fMNO5Ptb-rDi4hTmtO7W9O6FaFsA@mail.gmail.com>
	<4F8D3AC7.1000305@redhat.com> <4F8D4AB3.5070909@redhat.com>
	<CACGw4H7BmYzt9SZN6iJyfpsjAnQ4yDKuELELXFr-UM33SPmkXQ@mail.gmail.com>
	<4F8D6374.9010703@redhat.com> <4F8D68FE.70503@redhat.com>
	<4F8D6BAA.9050000@redhat.com>
	<20120417155411.GI14177@redhat.com> <4F8DAA7E.908@redhat.com>
	<20120417174046.GM14177@redhat.com>
Message-ID: <4F8DAE7F.1050800@redhat.com>

On 04/17/2012 06:40 PM, Deepak Bhole wrote:
> Besides, this sounds a lot like a yum bug to me.

Can you explain that?  I don't understand how this can possibly
be a bug in yum.

Andrew.



From dbhole at redhat.com  Tue Apr 17 11:16:25 2012
From: dbhole at redhat.com (Deepak Bhole)
Date: Tue, 17 Apr 2012 14:16:25 -0400
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its name should be openjdk-plugin !
In-Reply-To: <4F8DAE7F.1050800@redhat.com>
References: <4F8D3AC7.1000305@redhat.com> <4F8D4AB3.5070909@redhat.com>
	<CACGw4H7BmYzt9SZN6iJyfpsjAnQ4yDKuELELXFr-UM33SPmkXQ@mail.gmail.com>
	<4F8D6374.9010703@redhat.com> <4F8D68FE.70503@redhat.com>
	<4F8D6BAA.9050000@redhat.com> <20120417155411.GI14177@redhat.com>
	<4F8DAA7E.908@redhat.com> <20120417174046.GM14177@redhat.com>
	<4F8DAE7F.1050800@redhat.com>
Message-ID: <20120417181625.GO14177@redhat.com>

* Andrew Haley <aph at redhat.com> [2012-04-17 14:11]:
> On 04/17/2012 06:40 PM, Deepak Bhole wrote:
> > Besides, this sounds a lot like a yum bug to me.
> 
> Can you explain that?  I don't understand how this can possibly
> be a bug in yum.
> 

icedtea-web provides java-1.6.0-openjdk-plugin

If it is not on the system, 'yum install java-1.6.0-openjdk-plugin' pulls
in icedtea-web. However on the same system, 
'yum install "java-1.6.0-openjdk*"' does not pull it in.

So yum is ignoring virtual provides when glob pattern matching is used,
which is why I think it is a yum bug.

Cheers,
Deepak


From ddadacha at redhat.com  Tue Apr 17 11:31:16 2012
From: ddadacha at redhat.com (Danesh Dadachanji)
Date: Tue, 17 Apr 2012 14:31:16 -0400
Subject: [rfc][icedtea-web] signed applets test
In-Reply-To: <4F868C04.20301@redhat.com>
References: <4F85501C.1080003@redhat.com> <4F85D38B.6060502@redhat.com>
	<4F868C04.20301@redhat.com>
Message-ID: <4F8DB6F4.9080601@redhat.com>



On 12/04/12 04:02 AM, Jiri Vanek wrote:
> On 04/11/2012 08:55 PM, Danesh Dadachanji wrote:
> ...
>>> There is question how to deal with -Xtrustall which is now useless when there is trusted
>>> certificate (all signed reproducers are right
>>> now signed with same cert, and when more to much reproducers will need to much different
>>> certificates this will need re-factoring
>>> probably too).
>>>
>>
>> I don't mind -Xtrustall staying, I think it helps for testing stuff on the fly, outside the test
>> suite. However, I'm not too strong about this so if you want to remove it, feel free.
>>
>
> Yap. I'm for to keep it inside too.
>
>>> After this change is in, the PR905 reproducer have sense to go in too.
>>>
>>
>> +1
>>
>>> changelog:
> ...
>> There are a few typos, it should be:
>>
>
> fixed .. I hope...
>

I missed a few last time. Sorry :S

+2012-04-11  Jiri Vanek  <jvanek at redhat.com>
+
+	Allowed signed appletes in automatic reproducers tests

s/appletes/applets

+	* tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.html:
+	html file for launching signed applet. It still is different from the one for
+	calling unsigned applets - red.

Is the " - red" bit at the end still relevant? In fact, I think the entire sentence isn't quite necessary anymore. I think we can 
recognize that if it's for launching a signed applet, it'd be a different page than launching an unsigned one. =)

IMO, "html file for launching signed applet." is enough. It's up to you if you want to keep it though. =)

+	* tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.jnlp:
+	jnlp file for lunched signed applet

s/lunched/launched

>> > diff -r cde6d59a2901 Makefile.am
>> > --- a/Makefile.am Thu Apr 05 10:57:16 2012 -0400
>> > +++ b/Makefile.am Wed Apr 11 11:32:36 2012 +0200
>> > @@ -23,6 +23,12 @@
>> > JNLP_TESTS_SERVER_DEPLOYDIR=$(TESTS_DIR)/jnlp_test_server
>> > JNLP_TESTS_DIR=$(TESTS_DIR)/jnlp_tests
>> > KEYSTORE_NAME=teststore.ks
>> > +KEYSTORE_PASS=123456789
>>
>> I'm curious, why was this password chosen over the regular "changeit"? I know that you're getting it
>> from below but I'm wondering if anyone knows why the original dev chose this over the normal one. I
>> would rather it be "changeit" for consistency's sake though. What do you think?
>>

I don't think you noticed this comment last time, any thoughts?

>> > +EXPORTED_CERT=icedteatests.crt
>> > +TEST_CERT_ALIAS=icedteaweb
>> > +PUBLIC_KEYSTORE=~/.icedtea/security/trusted.certs
>> > +PUBLIC_PASS=changeit
>> > +
>>
>> [snip]
>>
>> > diff -r cde6d59a2901 tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.html
>> > --- /dev/null Thu Jan 01 00:00:00 1970 +0000
>> > +++ b/tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.html Wed Apr 11
>> 11:32:36 2012 +0200
>>
>> Heh, nice failure message. ;) It's because the applet was eventually killed, right?
>>
>> I'm worried that such a harsh failure message will throw testers off, they may not realize it is
>> meant to fail to run. Thoughts? It might be useful to add a "(This applet was killed, it should not
>> be running)" message too?
>
> nn - First reason was to distinguish normal applet's page/signed applet's page, then I got evil mind, some nice memories to blue death
> remembered 1.4, and result was this distinguisher :)
>
> I have removed it, and restoree original red. This was putting to big effort for test-writers. However, this can be isnpiration for
> feature ;)

Okay. =)

>>
>> [snip]
>>
>> diff -r cde6d59a2901 tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.html
>> --- /dev/null Thu Jan 01 00:00:00 1970 +0000
>> +++ b/tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.html Wed Apr 11 11:32:36
>> 2012 +0200
>> [...]
>> > +<vendor>NetX</vendor>
>> > +<homepage href="http://jnlp.sourceforge.net/netx/"/>
>>
>> Please change these to use IcedTea and the test page[1], thanks.
>>
> grrr. Done. Thanx for warning.
>> [snip]
>>
>> > diff -r cde6d59a2901 tests/jnlp_tests/signed/AppletTestSigned/resources/bd.css
>> > --- /dev/null Thu Jan 01 00:00:00 1970 +0000
>> > +++ b/tests/jnlp_tests/signed/AppletTestSigned/resources/bd.css Wed Apr 11 11:32:36 2012 +0200
>>
>> Shouldn't this have a copyright header too? Otherwise if it's easier, you can include it directly in
>> the HTML file instead of a new file.
>
> I n case blue death like message will go in, then it definitely will be good idea to have separate css file and so not to write it
> again and again...

Hmm okay, something to keep in mind if it does go in then.

>>
>> [snip]
>>
>> > diff -r cde6d59a2901 tests/jnlp_tests/signed/AppletTestSigned/srcs/AppletTestSigned.java
>> > --- /dev/null Thu Jan 01 00:00:00 1970 +0000
>> > +++ b/tests/jnlp_tests/signed/AppletTestSigned/srcs/AppletTestSigned.java Wed Apr 11 11:32:36
>> 2012 +0200
>> > @@ -0,0 +1,82 @@
>> > +
>> > +import java.applet.Applet;
>> > +
>> > +/* AppletTestSigned.java
>> > +Copyright (C) 2011 Red Hat, Inc.
>>
>> s/2011/2012/
>>
>>
>> [snip]
>>
>> > diff -r cde6d59a2901 tests/jnlp_tests/signed/AppletTestSigned/testcases/AppletTestSignedTests.java
>> > --- /dev/null Thu Jan 01 00:00:00 1970 +0000
>> > +++ b/tests/jnlp_tests/signed/AppletTestSigned/testcases/AppletTestSignedTests.java Wed Apr 11
>> 11:32:36 2012 +0200
>> > @@ -0,0 +1,100 @@
>> > +/* AppletTestTests.java
>> > +Copyright (C) 2011 Red Hat, Inc.
>>
>> s/2011/2012/
>>
>> [snip]
>>
>> > + Assert.assertTrue("AppletTestSigned stdout should contains " + s3 + " bud didn't",
>> pr.stdout.contains(s3));
>> > + String s0 = "AppletTestSigned was started";
>> > + Assert.assertTrue("AppletTestSigned stdout should contains " + s0 + " bud didn't",
>> pr.stdout.contains(s0));
>> > + String s1 = "value1";
>> > + Assert.assertTrue("AppletTestSigned stdout should contains " + s1 + " bud didn't",
>> pr.stdout.contains(s1));
>> > + String s2 = "value2";
>> > + Assert.assertTrue("AppletTestSigned stdout should contains " + s2 + " bud didn't",
>> pr.stdout.contains(s2));
>> > + String s4 = "AppletTestSigned was stopped";
>> > + Assert.assertFalse("AppletTestSigned stdout shouldn't contains " + s4 + " bud did",
>> pr.stdout.contains(s4));
>> > + String s5 = "AppletTestSigned will be destroyed";
>> > + Assert.assertFalse("AppletTestSigned stdout shouldn't contains " + s5 + " bud did",
>> pr.stdout.contains(s5));
>> > + String ss = "xception";
>> > + Assert.assertFalse("AppletTestSigned stderr should not contains " + ss + " but did",
>> pr.stderr.contains(ss));
>>
>> For "AppletTestSigned stdout should contains ", s/ contains / contain / (without the s). Also
>> s/bud/but/ =)
>
> All above should e fixed. Thanx for review!
>

Awesome, thanks! After the above typos are fixed, go ahead and push to HEAD.

Cheers,
Danesh


From aph at redhat.com  Tue Apr 17 11:37:21 2012
From: aph at redhat.com (Andrew Haley)
Date: Tue, 17 Apr 2012 19:37:21 +0100
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its name should be openjdk-plugin !
In-Reply-To: <20120417181625.GO14177@redhat.com>
References: <4F8D3AC7.1000305@redhat.com> <4F8D4AB3.5070909@redhat.com>
	<CACGw4H7BmYzt9SZN6iJyfpsjAnQ4yDKuELELXFr-UM33SPmkXQ@mail.gmail.com>
	<4F8D6374.9010703@redhat.com> <4F8D68FE.70503@redhat.com>
	<4F8D6BAA.9050000@redhat.com>
	<20120417155411.GI14177@redhat.com> <4F8DAA7E.908@redhat.com>
	<20120417174046.GM14177@redhat.com> <4F8DAE7F.1050800@redhat.com>
	<20120417181625.GO14177@redhat.com>
Message-ID: <4F8DB861.8000102@redhat.com>

On 04/17/2012 07:16 PM, Deepak Bhole wrote:
> * Andrew Haley <aph at redhat.com> [2012-04-17 14:11]:
>> On 04/17/2012 06:40 PM, Deepak Bhole wrote:
>>> Besides, this sounds a lot like a yum bug to me.
>>
>> Can you explain that?  I don't understand how this can possibly
>> be a bug in yum.
>>
> 
> icedtea-web provides java-1.6.0-openjdk-plugin

Oh, I see.

> If it is not on the system, 'yum install java-1.6.0-openjdk-plugin' pulls
> in icedtea-web. However on the same system, 
> 'yum install "java-1.6.0-openjdk*"' does not pull it in.
> 
> So yum is ignoring virtual provides when glob pattern matching is used,
> which is why I think it is a yum bug.

Definitely.  Thanks for the explanation.

Andrew.



From dbhole at redhat.com  Tue Apr 17 11:44:19 2012
From: dbhole at redhat.com (Deepak Bhole)
Date: Tue, 17 Apr 2012 14:44:19 -0400
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its name should be openjdk-plugin !
In-Reply-To: <4F8DB861.8000102@redhat.com>
References: <CACGw4H7BmYzt9SZN6iJyfpsjAnQ4yDKuELELXFr-UM33SPmkXQ@mail.gmail.com>
	<4F8D6374.9010703@redhat.com> <4F8D68FE.70503@redhat.com>
	<4F8D6BAA.9050000@redhat.com> <20120417155411.GI14177@redhat.com>
	<4F8DAA7E.908@redhat.com> <20120417174046.GM14177@redhat.com>
	<4F8DAE7F.1050800@redhat.com> <20120417181625.GO14177@redhat.com>
	<4F8DB861.8000102@redhat.com>
Message-ID: <20120417184419.GQ14177@redhat.com>

* Andrew Haley <aph at redhat.com> [2012-04-17 14:37]:
> On 04/17/2012 07:16 PM, Deepak Bhole wrote:
> > * Andrew Haley <aph at redhat.com> [2012-04-17 14:11]:
> >> On 04/17/2012 06:40 PM, Deepak Bhole wrote:
> >>> Besides, this sounds a lot like a yum bug to me.
> >>
> >> Can you explain that?  I don't understand how this can possibly
> >> be a bug in yum.
> >>
> > 
> > icedtea-web provides java-1.6.0-openjdk-plugin
> 
> Oh, I see.
> 
> > If it is not on the system, 'yum install java-1.6.0-openjdk-plugin' pulls
> > in icedtea-web. However on the same system, 
> > 'yum install "java-1.6.0-openjdk*"' does not pull it in.
> > 
> > So yum is ignoring virtual provides when glob pattern matching is used,
> > which is why I think it is a yum bug.
> 
> Definitely.  Thanks for the explanation.
> 

No problem. For the record, I've opened a bug against yum:
https://bugzilla.redhat.com/show_bug.cgi?id=813432

Cheers,
Deepak


From fcassia at gmail.com  Tue Apr 17 12:15:27 2012
From: fcassia at gmail.com (Fernando Cassia)
Date: Tue, 17 Apr 2012 16:15:27 -0300
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream, its
	name should be openjdk-plugin !
In-Reply-To: <4F8D68FE.70503@redhat.com>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>
	<4F8B0820.7050001@redhat.com>
	<CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>
	<87lilwsule.fsf@mid.deneb.enyo.de>
	<CACGw4H4c+dYKtNFaP+UKJg3ZEtMp0RZGavGRMjvbms9PGJoErg@mail.gmail.com>
	<87aa2cstbv.fsf@mid.deneb.enyo.de>
	<CACGw4H5yWav9s92ttbEdJ2CGDf1TO_FW+MV2sefHOHgUvMr72A@mail.gmail.com>
	<4F8BD917.9070500@redhat.com> <4F8BE44E.5070003@redhat.com>
	<4F8BE6E4.7090609@redhat.com>
	<CACGw4H4K+oyHR9jeLoqnsQbGCtSPig-FbpbdxY85FEiWyD01kg@mail.gmail.com>
	<4F8BF674.4020809@redhat.com>
	<CACGw4H6-e=67ZkdwDfj4S9fMNO5Ptb-rDi4hTmtO7W9O6FaFsA@mail.gmail.com>
	<4F8D3AC7.1000305@redhat.com> <4F8D4AB3.5070909@redhat.com>
	<CACGw4H7BmYzt9SZN6iJyfpsjAnQ4yDKuELELXFr-UM33SPmkXQ@mail.gmail.com>
	<4F8D6374.9010703@redhat.com> <4F8D68FE.70503@redhat.com>
Message-ID: <CACGw4H5O_W+wi7Hxe0gd35z=a0F=pfOis9rvNb2A5EWDo+zCug@mail.gmail.com>

On Tue, Apr 17, 2012 at 09:58, Pavel Tisnovsky <ptisnovs at redhat.com> wrote:

> Safer is to use "*openjdk*"


Just checked my root .bash_history

$cat .bash_history | grep 'yum install'

yum install java-1.7.0-openjdk*
yum install mplayer*
yum install wine*
yum install audacious-plugins*
yum install gnome-appearance*

FWIW
FC

-- 
During times of Universal Deceit, telling the truth becomes a revolutionary
act
Durante ?pocas de Enga?o Universal, decir la verdad se convierte en un Acto
Revolucionario
- George Orwell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120417/723c134c/attachment.html 

From fcassia at gmail.com  Tue Apr 17 12:17:47 2012
From: fcassia at gmail.com (Fernando Cassia)
Date: Tue, 17 Apr 2012 16:17:47 -0300
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream, its
	name should be openjdk-plugin !
In-Reply-To: <20120417184419.GQ14177@redhat.com>
References: <CACGw4H7BmYzt9SZN6iJyfpsjAnQ4yDKuELELXFr-UM33SPmkXQ@mail.gmail.com>
	<4F8D6374.9010703@redhat.com> <4F8D68FE.70503@redhat.com>
	<4F8D6BAA.9050000@redhat.com> <20120417155411.GI14177@redhat.com>
	<4F8DAA7E.908@redhat.com> <20120417174046.GM14177@redhat.com>
	<4F8DAE7F.1050800@redhat.com> <20120417181625.GO14177@redhat.com>
	<4F8DB861.8000102@redhat.com> <20120417184419.GQ14177@redhat.com>
Message-ID: <CACGw4H5-rer3_GPknwmi-k6g6ircNcogepiXD=3oJYHu2p_sdw@mail.gmail.com>

On Tue, Apr 17, 2012 at 15:44, Deepak Bhole <dbhole at redhat.com> wrote:

> No problem. For the record, I've opened a bug against yum:
> https://bugzilla.redhat.com/show_bug.cgi?id=813432
>

Thanks!
This is the first step towards a (partial) solution.

Of course, it'd be a universal solution if Icedtea-web would be integrated
into OpenJDK or renamed OpenJDK-plugin. ;-)

Thanks again
FC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120417/0a0e83bb/attachment.html 

From jgh at FreeBSD.org  Tue Apr 17 12:35:40 2012
From: jgh at FreeBSD.org (Jason Helfman)
Date: Tue, 17 Apr 2012 12:35:40 -0700
Subject: porting icedtea6 to FreeBSD
In-Reply-To: <CAMuy=+gA8o6khgtA3U3BZ_Ug=E9XSO2rr9m2w2qTqAR2OQES_A@mail.gmail.com>
References: <CAMuy=+jM4kWYJ+FpvEF8s=jo9LRmvgdW-1gAN9QQhFt0Xk4uEg@mail.gmail.com>
	<73684032-8d02-406f-8af2-e43e59f6c7dd@zmail17.collab.prod.int.phx2.redhat.com>
	<CAMuy=+gA8o6khgtA3U3BZ_Ug=E9XSO2rr9m2w2qTqAR2OQES_A@mail.gmail.com>
Message-ID: <20120417193540.GA15370@dormouse.experts-exchange.com>

On Tue, Apr 17, 2012 at 08:08:43AM -0700, Jason Helfman thus spake:
>On Tue, Apr 17, 2012 at 7:56 AM, Andrew Hughes <ahughes at redhat.com> wrote:
>
>> ----- Original Message -----
>> >
>> >
>> >
>> > On Tue, Apr 17, 2012 at 4:51 AM, Andrew Hughes < ahughes at redhat.com >
>> > wrote:
>> >
>> >
>> >
>> > ----- Original Message -----
>> > > On Mon, Apr 16, 2012 at 09:59:00AM -0400, Andrew Hughes thus spake:
>> > > >> Any thoughts on any of this?
>> > > >> Thanks, again.
>> > > >>
>> > > >> -jgh
>> > > >
>> > > >What are you doing here?
>> > > >
>> > > >/usr/bin/sed -i.bak -e 's|--dry-run||g'
>> > >
>> >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.am
>> > >
>> >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.in
>> > > >/usr/bin/sed -i.bak -e 's|--check|-q|g'
>> > >
>> >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.am
>> > >
>> >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.in
>> > > >
>> > > >If you're removing --dry-run, you're going to be applying the
>> > > >patch
>> > > >twice, which is why it's failing.
>> > > >--
>> > > >Andrew :)
>> > >
>> > > I've modified this to test the patch which in FreeBSD is the "-C"
>> > > switch,
>> > > and the "-q" is for SHASUM's to only output the hash.
>> > >
>> > > I was able to get much further in the build! Any thoughts on why
>> > > this
>> > > patch
>> > > was seen as already applied?
>> > >
>> >
>> > Because the build tests the patch, then applies it if that passes. If
>> > you
>> > removed --dry-run from the first invocation and didn't replace it
>> > with -C,
>> > you'd be applying the patch twice instead.
>> >
>> >
>> >
>> > That is what I have done, though. --dry-run is being replaced with -C
>> > in the build.
>> > Is something else showing up?
>> >
>> > -jgh
>> >
>> >
>>
>> And it's still failing in the same way?  I thought you said you'd got much
>> further... :-S
>> --
>> Andrew :)
>>
>
>Yes, it is failing in the same way but much further into the build.
>Initially, it would fail at the first/second patch.
>I attached the latest buildlog to my email last night. It should show the
>issue, and with what patch the problem
>was with.
>
>-jgh

I believe I found part of the issue. In the patchset, the file
openjdk/7034464-hugepage.patch has a number of repatched instances within
os_linux.cpp, which is more than likely the cause of this issue. It is being
patched twice.

Starting at line 40, and another starting at line 209.

For instance, both are adding this information to the same file:

47 +// Define MAP_HUGETLB here so we can build HotSpot on old systems.
48 +#ifndef MAP_HUGETLB
49 +#define MAP_HUGETLB 0x40000
50 +#endif

227 +// Define MAP_HUGETLB here so we can build HotSpot on old systems.
228 +#ifndef MAP_HUGETLB
229 +#define MAP_HUGETLB 0x40000
230 +#endif

-jgh

--
Jason Helfman         | FreeBSD Committer
jgh at FreeBSD.org       | http://people.freebsd.org/~jgh


From ddadacha at redhat.com  Tue Apr 17 13:28:19 2012
From: ddadacha at redhat.com (Danesh Dadachanji)
Date: Tue, 17 Apr 2012 16:28:19 -0400
Subject: [RFC][icedtea-web] Unit tests for the new updates to JarSIgner
	(incomplete)
In-Reply-To: <4F8C81C7.6030501@redhat.com>
References: <4F7A1037.7060405@redhat.com> <4F7CDAF7.6090503@redhat.com>
	<4F7F66C2.8060506@redhat.com> <4F821CDE.9090101@redhat.com>
	<4F8C81C7.6030501@redhat.com>
Message-ID: <4F8DD263.2040506@redhat.com>



On 16/04/12 04:32 PM, Danesh Dadachanji wrote:
> On 08/04/12 07:18 PM, Omair Majid wrote:
>> On 04/06/2012 05:57 PM, Danesh Dadachanji wrote:
>
> [snip]
>
>>> I've attached a new patch that loosens up the code a bit, I've padded
>>> newlines above (and below) the chunk of asserts. There are a few more
>>> modifications as follows.
>>>
>>> 1) The new patch also brings in the changeset that renames JarSigner to
>>> JarCertVerifier[1] so hopefully it won't throw reviewers off too much.
>>
>> Great :)
>>
>>> 2) In the tests that run 1 entry than 3 entries, I've reset
>>> JarCertVerifier to a new instance when the three-entry vector is used. I
>>> think this may cause confusion later on because there would have been
>>> cases where the JarCertVerifier would have totalSignableEntries = 4
>>> instead of 3.
>>
>> Hm... If you are doing this, I would recommend you go all the way and
>> split the 1-entry/3-entry tests into different methods to isolate the
>> tests completely.
>>
>
> Done! It looks a little bit more heavy and jumps up to 22 unit tests. All in all though, I think it looks good.
>
>>> 3) Lastly, I've added a new set of asserts using the following two methods:
>>>
>>> /**
>>> * Checks if the provided cert path has signed any of the jars
>>> associated
>>> * with the cert verifier.
>>> * @param certPath The cert path of the potential signer.
>>> * @return Whether or not the cert path represents one of the
>>> signers of
>>> * a jar associated with the verifier.
>>> */
>>> boolean hasJarSigner(CertPath certPath)
>>
>> The name is not very descriptive. How about something like
>> certHasSignedAnyJar? Also, why a certPath instead of a cert?
>>
>
> Yeah, not too sure what I was thinking when I came up with the name. Please see the comment below.
>
>>> /**
>>> * Calculate the number of signers all the jars have in total.
>>> *
>>> * Note this is not the number of common signers across all jars. It is
>>> * the number of common signers each jar has with respect to itself,
>>> * totalled together across the other jars.
>>> * @return The number of signers that have signed at least one jar
>>> entirely.
>>> */
>>> int numSigners()
>>>
>>
>> Likewise, this name doesn't convey much. I am still trying to figure out
>> what this method does.
>>
>> Are these methods public? Any reason why we are adding these (or are
>> they just for tests)gf?
>
> Yes, these methods are just for tests)gf only. ;)
>
> I have rethought these 2 methods and decided not to use them. What they did was essentially grab the key set of the hash map that
> managed all the signers, then check if the list contains the CertPath or return the size of the list. Instead of creating extra methods
> for duplicate info, I'm just going to use JarCertVerifier.getCerts() in the tests.
>
> Here's a little background info on the key set. If the CertPath is a key of the hash map, that means that this CertPath has signed at
> least one jar entirely (namely, every signable entry has been signed). So if the tests run as expected, the end result is one of the
> signers being set as the key (if expected). The size is also checked to make sure nothing else slipped in by mistake. I've changed the
> asserts to use this instead. I hope this is more clear!
>
> Main differences in this patch:
> 1) Separate single-entry and many-entry tests into their own methods
> 2) Rework calls to numSigners and hasJarSigner to use jcv.getCerts()'s .contains(signer) and .size()
>
> Thanks for the review!
>

In my efforts to separate adding checks for expiring certs[1] into its own patch, I seem to have removed it from my original changes 
from the overall update. :(

I've added a new signer, one that is not yet valid (valid starting $TOMORROW) and expires within 6 months ($NOW + 3). I've used this in 
2 new unit tests, *ExpiringAndNotYetValidSigner(), that check that the result is SIGNED_NOT_OK but also that R("SHasExpiringCert") is 
in the details list.

On that note, in the next update to this patch, I'll add checks for issues in the details list each time I expect there to be a signer 
in the hash map.

Cheers,
Danesh

[1] http://icedtea.classpath.org/hg/icedtea-web/rev/eb3a40549623
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jar-signer-tests-04.patch
Type: text/x-patch
Size: 36782 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120417/2ac73a94/jar-signer-tests-04.patch 

From jvanek at redhat.com  Wed Apr 18 02:12:03 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Wed, 18 Apr 2012 11:12:03 +0200
Subject: [rfc][icedtea-web]encoding test
In-Reply-To: <4F8D7655.8070206@redhat.com>
References: <4F8D7655.8070206@redhat.com>
Message-ID: <4F8E8563.6060509@redhat.com>

On 04/17/2012 03:55 PM, Jiri Vanek wrote:
> Hi!
>
> This is reproducer for incorrect behaviour of icedtea-web when jnlps are in "unexpected" encoding.
> We are expecting utf-8 everywhere, but windows users can very easily expose jnlps in different one.
> And we should process them for unix user correctly.
> I have used ISO-8859-2 encoding to torture icedtea-web.
> All tests to this encoding have failed. I have added also set of UTF-8 tests above those cases, and
> all those are passing (so test should be correct).
>
> Sorry that diff is not in classical patch format, but diff tools have not cooperate well with mixed
> utf8/non-utf8 content. And it is just adding files so "applying" should be simple as with patch.
>
> Please note, that this adds 3 more passing and three more failing tests - which are representing the
> issue. Maybe annotation marking this "representatives" will become necessary soon?
>
> The name of the directory is so weird because I wanted to create resource containing those unhappy
> characters. (The engine creates nameOfDirectory.jar)
>
> I'm going to check this also for applets, but here launching informations are provided by brpwser so
> it should be ok.
>
> Changelog:
> 2012-04-17 Jiri Vanek <jvanek at redhat.com>
>
> added encodings reproducer
> * tests/jnlp_tests/simple/encodingTests????????????????????????: new reproducer
> * tests/jnlp_tests/simple/encodingTests????????????????????????/srcs/encodingTest.java:
> main class and method of new encodingTests????????????????????????.jar
> * tests/jnlp_tests/simple/encodingTests????????????????????????/testcases/encodingTestTest.java:
> testcases for jnlps of this reproducers
> * tests/jnlp_tests/simple/encodingTests????????????????????????/resources:
> three utf-8 and three iso-8859-2 jnlp files
>
>

  Changelog:
  2012-04-18 Jiri Vanek <jvanek at redhat.com>

  added encodings reproducer
  * tests/jnlp_tests/simple/encodingTests????????????????????????: new reproducer
  * tests/jnlp_tests/simple/encodingTests????????????????????????/srcs/encodingTest.java:
  main class/main applet class and method of new encodingTests????????????????????????.jar
  * tests/jnlp_tests/simple/encodingTests????????????????????????/testcases/encodingTestTest.java:
  testcases for jnlps of this reproducers
  * tests/jnlp_tests/simple/encodingTests????????????????????????/resources:
  four utf-8 and four iso-8859-2 jnlp files and one utf-8 and one iso-8859-2 html files


As expected, applets behaviour (in firefox)  is correct due to encoding processed by browser
Applets launched from jnlp suffers in same way as  applications.

J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: encodingReproducersWithApplets.tar.gz
Type: application/x-gzip
Size: 4836 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120418/1181b241/encodingReproducersWithApplets.tar.gz 

From ptisnovs at redhat.com  Wed Apr 18 03:05:46 2012
From: ptisnovs at redhat.com (Pavel Tisnovsky)
Date: Wed, 18 Apr 2012 12:05:46 +0200
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its name should be openjdk-plugin !
In-Reply-To: <CACGw4H5O_W+wi7Hxe0gd35z=a0F=pfOis9rvNb2A5EWDo+zCug@mail.gmail.com>
References: <CACGw4H59CnRY=0Qpre4ysKptX5C+6BsMtvG6yKCMvrFJ5FNV5w@mail.gmail.com>	<4F8B0820.7050001@redhat.com>	<CACGw4H4EDgc5eb2gQWMo6FscNpJkhQ2ZJfhJ-kh=TGFtZT3qNg@mail.gmail.com>	<87lilwsule.fsf@mid.deneb.enyo.de>	<CACGw4H4c+dYKtNFaP+UKJg3ZEtMp0RZGavGRMjvbms9PGJoErg@mail.gmail.com>	<87aa2cstbv.fsf@mid.deneb.enyo.de>	<CACGw4H5yWav9s92ttbEdJ2CGDf1TO_FW+MV2sefHOHgUvMr72A@mail.gmail.com>	<4F8BD917.9070500@redhat.com>	<4F8BE44E.5070003@redhat.com>	<4F8BE6E4.7090609@redhat.com>	<CACGw4H4K+oyHR9jeLoqnsQbGCtSPig-FbpbdxY85FEiWyD01kg@mail.gmail.com>	<4F8BF674.4020809@redhat.com>	<CACGw4H6-e=67ZkdwDfj4S9fMNO5Ptb-rDi4hTmtO7W9O6FaFsA@mail.gmail.com>	<4F8D3AC7.1000305@redhat.com>	<4F8D4AB3.5070909@redhat.com>	<CACGw4H7BmYzt9SZN6iJyfpsjAnQ4yDKuELELXFr-UM33SPmkXQ@mail.gmail.com>	<4F8D6374.9010703@redhat.com>	<4F8D68FE.70503@redhat.com>
	<CACGw4H5O_W+wi7Hxe0gd35z=a0F=pfOis9rvNb2A5EWDo+zCug@mail.gmail.com>
Message-ID: <4F8E91FA.5070900@redhat.com>

Fernando Cassia wrote:
> 
> 
> On Tue, Apr 17, 2012 at 09:58, Pavel Tisnovsky <ptisnovs at redhat.com
> <mailto:ptisnovs at redhat.com>> wrote:
> 
>     Safer is to use "*openjdk*"
> 
> 
> Just checked my root .bash_history
> 
> $cat .bash_history | grep 'yum install'
> 
> yum install java-1.7.0-openjdk*
> yum install mplayer*
> yum install wine*
> yum install audacious-plugins*
> yum install gnome-appearance*

yeah, that's wrong of course :-) and you could be in trouble in some situations

What about to run "yum install wine*" from a directory where there are files
like wine1  wine2.txt  winefoobat etc. etc...

> 
> FWIW
> FC
> 
> -- 
> During times of Universal Deceit, telling the truth becomes a
> revolutionary act
> Durante ?pocas de Enga?o Universal, decir la verdad se convierte en un
> Acto Revolucionario
> - George Orwell
> 



From jvanek at redhat.com  Wed Apr 18 03:25:23 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Wed, 18 Apr 2012 12:25:23 +0200
Subject: [rfc][icedtea-web] signed applets test
In-Reply-To: <4F8DB6F4.9080601@redhat.com>
References: <4F85501C.1080003@redhat.com> <4F85D38B.6060502@redhat.com>
	<4F868C04.20301@redhat.com> <4F8DB6F4.9080601@redhat.com>
Message-ID: <4F8E9693.8070608@redhat.com>

On 04/17/2012 08:31 PM, Danesh Dadachanji wrote:
>
>
> I missed a few last time. Sorry :S

Apologise on my side, thanx for precession.
>
> +2012-04-11  Jiri Vanek <jvanek at redhat.com>
> +
> +    Allowed signed appletes in automatic reproducers tests
>
> s/appletes/applets
>
> +    * tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.html:
> +    html file for launching signed applet. It still is different from the one for
> +    calling unsigned applets - red.
>
> Is the " - red" bit at the end still relevant? In fact, I think the entire sentence isn't quite
> necessary anymore. I think we can recognize that if it's for launching a signed applet, it'd be a
> different page than launching an unsigned one. =)
>
> IMO, "html file for launching signed applet." is enough. It's up to you if you want to keep it
> though. =)

I have kept it in with one correction which escaped you and maybe give more sense -   It still -> 
It's style
>
> +    * tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.jnlp:
> +    jnlp file for lunched signed applet
>
> s/lunched/launched
>
>>> > diff -r cde6d59a2901 Makefile.am
>>> > --- a/Makefile.am Thu Apr 05 10:57:16 2012 -0400
>>> > +++ b/Makefile.am Wed Apr 11 11:32:36 2012 +0200
>>> > @@ -23,6 +23,12 @@
>>> > JNLP_TESTS_SERVER_DEPLOYDIR=$(TESTS_DIR)/jnlp_test_server
>>> > JNLP_TESTS_DIR=$(TESTS_DIR)/jnlp_tests
>>> > KEYSTORE_NAME=teststore.ks
>>> > +KEYSTORE_PASS=123456789
>>>
>>> I'm curious, why was this password chosen over the regular "changeit"? I know that you're getting it
>>> from below but I'm wondering if anyone knows why the original dev chose this over the normal one. I
>>> would rather it be "changeit" for consistency's sake though. What do you think?
>>>
>
> I don't think you noticed this comment last time, any thoughts?
Ah! I noticed, I thought about it and I forgot to wrote it.

I chose this password :) It is private testing repository generated, filed and deleted during 
reproducers run.And so it have also some unimportant password.
I have renamed the variables to give more sense.
PRIVATE_KEYSTORE_NAME=teststore.ks
PRIVATE_KEYSTORE_PASS=123456789
EXPORTED_TEST_CERT=icedteatests.crt
TEST_CERT_ALIAS=icedteaweb
PUBLIC_KEYSTORE=~/.icedtea/security/trusted.certs
PUBLIC_KEYSTORE_PASS=changeit

I'm for keeping the password as it is, as it is not supposed to be changed, but just serve it 
purpose and be discarded.
>
>>> > +EXPORTED_CERT=icedteatests.crt
...
>>
>
> Awesome, thanks! After the above typos are fixed, go ahead and push to HEAD.

Thanx! pushed!
>
> Cheers,
> Danesh

-------------- next part --------------
A non-text attachment was scrubbed...
Name: sgnw.diff
Type: text/x-patch
Size: 19473 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120418/114f0f32/sgnw.diff 

From jvanek at icedtea.classpath.org  Wed Apr 18 03:27:52 2012
From: jvanek at icedtea.classpath.org (jvanek at icedtea.classpath.org)
Date: Wed, 18 Apr 2012 10:27:52 +0000
Subject: /hg/icedtea-web: Added possibility to run signed applets during ...
Message-ID: <hg.14dcb4fb43ac.1334744872.8643924302249223276@icedtea.classpath.org>

changeset 14dcb4fb43ac in /hg/icedtea-web
details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=14dcb4fb43ac
author: Jiri Vanek <jvanek at redhat.com>
date: Wed Apr 18 12:28:08 2012 +0200

	Added possibility to run signed applets during reproducers runs.
	Added example reproducer.


diffstat:

 ChangeLog                                                                     |  27 ++
 Makefile.am                                                                   |  39 ++-
 tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.html      |  46 ++++
 tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.jnlp      |  63 ++++++
 tests/jnlp_tests/signed/AppletTestSigned/srcs/AppletTestSigned.java           |  82 ++++++++
 tests/jnlp_tests/signed/AppletTestSigned/testcases/AppletTestSignedTests.java |  99 ++++++++++
 6 files changed, 345 insertions(+), 11 deletions(-)

diffs (432 lines):

diff -r 2a13d6d1b57c -r 14dcb4fb43ac ChangeLog
--- a/ChangeLog	Tue Apr 17 16:43:11 2012 +0200
+++ b/ChangeLog	Wed Apr 18 12:28:08 2012 +0200
@@ -1,3 +1,30 @@
+2012-04-18  Jiri Vanek  <jvanek at redhat.com>
+
+	Allowed signed applets in automatic reproducers tests
+	* tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.html:
+	html file for launching signed applet. Its style is different from the one for
+	calling unsigned applets - red. 
+	* tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.jnlp:
+	jnlp file for launched signed applet
+	* tests/jnlp_tests/signed/AppletTestSigned/srcs/AppletTestSigned.java
+	body of signed applet
+	* tests/jnlp_tests/signed/AppletTestSigned/testcases/AppletTestSignedTests.java:
+	(AppletTestSignedTest): testing method to launch signed applet in javaws
+	(AppletTestSignedFirefoxTest): testing method to launch signed applet in
+	browser
+	* Makefile.am: PUBLIC_KEYSTORE_PASS, EXPORTED_TEST_CERT, TEST_CERT_ALIAS,
+	PUBLIC_KEYSTORE PUBLIC_KEYSTORE_PASS: new global variables holding
+	keystores' credentials
+	(clean-local): clean-bootstrap-directory moved to be last one, as keytool
+	is necessary for removing certificate
+	(EXPORTED_TEST_CERT): new target exporting certificate from testing keystore
+	(stamps/netx-dist-tests-import-cert-to-public): new target to import
+	certificate to PUBLIC_KEYSTORE
+	(netx-dist-tests-remove-cert-from-public): new target removing testing
+	certificate from PUBLIC_KEYSTORE
+	(clean-netx-dist-tests): now depends on netx-dist-tests-remove-cert-from-public
+	and is removing EXPORTED_TEST_CERT file
+
 2012-04-17  Jiri Vanek <jvanek at redhat.com>
 
 	Rewritten DeadLockTestTest to stop failing in more then 1/2 of cases
diff -r 2a13d6d1b57c -r 14dcb4fb43ac Makefile.am
--- a/Makefile.am	Tue Apr 17 16:43:11 2012 +0200
+++ b/Makefile.am	Wed Apr 18 12:28:08 2012 +0200
@@ -22,7 +22,12 @@
 JNLP_TESTS_ENGINE_DIR=$(TESTS_DIR)/netx/jnlp_testsengine
 JNLP_TESTS_SERVER_DEPLOYDIR=$(TESTS_DIR)/jnlp_test_server
 JNLP_TESTS_DIR=$(TESTS_DIR)/jnlp_tests
-KEYSTORE_NAME=teststore.ks
+PRIVATE_KEYSTORE_NAME=teststore.ks
+PRIVATE_KEYSTORE_PASS=123456789
+EXPORTED_TEST_CERT=icedteatests.crt
+TEST_CERT_ALIAS=icedteaweb
+PUBLIC_KEYSTORE=~/.icedtea/security/trusted.certs
+PUBLIC_KEYSTORE_PASS=changeit
 
 JUNIT_RUNNER_JAR=$(abs_top_builddir)/junit-runner.jar
 UNIT_CLASS_NAMES = $(abs_top_builddir)/unit_class_names
@@ -142,8 +147,8 @@
 
 check-local: $(RHINO_TESTS) $(JUNIT_TESTS)
 
-clean-local: clean-netx clean-plugin clean-liveconnect clean-extra clean-bootstrap-directory \
- clean-native-ecj clean-launchers clean-desktop-files clean-docs clean-tests
+clean-local: clean-netx clean-plugin clean-liveconnect clean-extra  \
+ clean-native-ecj clean-launchers clean-desktop-files clean-docs clean-tests clean-bootstrap-directory
 	if [ -e stamps ] ; then \
 	  rmdir stamps ; \
 	fi
@@ -506,19 +511,30 @@
 	touch $@
 
 stamps/netx-dist-tests-sign-some-reproducers.stamp: stamps/netx-dist-tests-prepare-reproducers.stamp
-	alias=icedteaweb; \
-	keystore=$(abs_top_builddir)/$(KEYSTORE_NAME); \
-	pass=123456789; \
-	$(BOOT_DIR)/bin/keytool -genkey -alias $$alias -keystore $$keystore -keypass $$pass -storepass $$pass -dname "cn=$$alias, ou=$$alias, o=$$alias, c=$$alias" ; \
+	keystore=$(abs_top_builddir)/$(PRIVATE_KEYSTORE_NAME); \
+	$(BOOT_DIR)/bin/keytool -genkey -alias $(TEST_CERT_ALIAS) -keystore $$keystore -keypass $(PRIVATE_KEYSTORE_PASS) -storepass $(PRIVATE_KEYSTORE_PASS) -dname "cn=$(TEST_CERT_ALIAS), ou=$(TEST_CERT_ALIAS), o=$(TEST_CERT_ALIAS), c=$(TEST_CERT_ALIAS)" ; \
 	  . $(abs_top_srcdir)/NEW_LINE_IFS ; \
 	signedReproducers=(`cat $(abs_top_builddir)/junit-jnlp-dist-signed.txt `); \
 	  IFS="$$IFS_BACKUP" ; \
 	for dir in "$${signedReproducers[@]}" ; do \
-	 $(BOOT_DIR)/bin/jarsigner -keystore $$keystore -storepass $$pass -keypass $$pass  "$(JNLP_TESTS_SERVER_DEPLOYDIR)/$$dir.jar"  $$alias ; \
+	 $(BOOT_DIR)/bin/jarsigner -keystore $$keystore -storepass $(PRIVATE_KEYSTORE_PASS) -keypass $(PRIVATE_KEYSTORE_PASS)  "$(JNLP_TESTS_SERVER_DEPLOYDIR)/$$dir.jar"  $(TEST_CERT_ALIAS) ; \
  	done ; \
  	mkdir -p stamps && \
  	touch $@
 
+#this always tries to remove  previous testcert
+$(EXPORTED_TEST_CERT): stamps/netx-dist-tests-sign-some-reproducers.stamp netx-dist-tests-remove-cert-from-public
+	keytool -export -alias $(TEST_CERT_ALIAS) -file $(EXPORTED_TEST_CERT) -storepass $(PRIVATE_KEYSTORE_PASS) -keystore $(PRIVATE_KEYSTORE_NAME) 
+
+stamps/netx-dist-tests-import-cert-to-public: $(EXPORTED_TEST_CERT)
+	yes | $(BOOT_DIR)/bin/keytool -import -alias $(TEST_CERT_ALIAS) -keystore $(PUBLIC_KEYSTORE) -storepass $(PUBLIC_KEYSTORE_PASS) -file $(EXPORTED_TEST_CERT); \
+ 	mkdir -p stamps && \
+ 	touch $@
+
+netx-dist-tests-remove-cert-from-public:
+	-$(BOOT_DIR)/bin/keytool -delete -alias $(TEST_CERT_ALIAS) -keystore $(PUBLIC_KEYSTORE) -storepass $(PUBLIC_KEYSTORE_PASS)
+	-rm -rf stamps/netx-dist-tests-import-cert-to-public
+
 netx-dist-tests-source-files.txt:
 	find $(JNLP_TESTS_ENGINE_SRCDIR) -name '*.java' | sort > $@
 
@@ -560,7 +576,7 @@
 
 stamps/run-netx-dist-tests.stamp: stamps/netx-dist.stamp extra-lib/about.jar stamps/plugin.stamp launcher.build/$(javaws) \
  javaws.desktop stamps/docs.stamp launcher.build/$(itweb_settings) itweb-settings.desktop \
- stamps/netx.stamp stamps/junit-jnlp-dist-dirs stamps/netx-dist-tests-sign-some-reproducers.stamp \
+ stamps/netx.stamp stamps/junit-jnlp-dist-dirs stamps/netx-dist-tests-import-cert-to-public \
  stamps/netx-dist-tests-compile.stamp stamps/netx-dist-tests-compile-testcases.stamp $(JUNIT_RUNNER_JAR) \
  $(TESTS_DIR)/$(REPORT_STYLES_DIRNAME) $(REPRODUCERS_CLASS_NAMES)
 	cd $(JNLP_TESTS_ENGINE_DIR) ; \
@@ -798,7 +814,7 @@
 	rm -rf  $(TESTS_DIR)/$(REPORT_STYLES_DIRNAME)/
 	rm -f  $(TESTS_DIR)/index*.html
 
-clean-netx-dist-tests: clean_tests_reports
+clean-netx-dist-tests: clean_tests_reports netx-dist-tests-remove-cert-from-public
 	rm -f netx-dist-tests-source-files.txt
 	rm -rf $(JNLP_TESTS_DIR)
 	rm -rf $(JNLP_TESTS_SERVER_DEPLOYDIR)
@@ -811,7 +827,8 @@
 	rm -f junit-jnlp-dist-simple.txt
 	rm -f junit-jnlp-dist-signed.txt
 	rm -f $(REPRODUCERS_CLASS_NAMES)
-	rm -f $(abs_top_builddir)/$(KEYSTORE_NAME)
+	rm -f $(abs_top_builddir)/$(PRIVATE_KEYSTORE_NAME)
+	rm -f $(EXPORTED_TEST_CERT)
 	rm -f stamps/run-netx-dist-tests.stamp
 
 clean-unit-test-code-coverage:
diff -r 2a13d6d1b57c -r 14dcb4fb43ac tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.html
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.html	Wed Apr 18 12:28:08 2012 +0200
@@ -0,0 +1,46 @@
+<!--
+
+This file is part of IcedTea.
+
+IcedTea is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+IcedTea is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with IcedTea; see the file COPYING.  If not, write to the
+Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+02110-1301 USA.
+
+Linking this library statically or dynamically with other modules is
+making a combined work based on this library.  Thus, the terms and
+conditions of the GNU General Public License cover the whole
+combination.
+
+As a special exception, the copyright holders of this library give you
+permission to link this library with independent modules to produce an
+executable, regardless of the license terms of these independent
+modules, and to copy and distribute the resulting executable under
+terms of your choice, provided that you also meet, for each linked
+independent module, the terms and conditions of the license of that
+module.  An independent module is a module which is not derived from
+or based on this library.  If you modify this library, you may extend
+this exception to your version of the library, but you are not
+obligated to do so.  If you do not wish to do so, delete this
+exception statement from your version.
+
+ -->
+<html><head></head><body bgcolor="red">
+<p>
+  <applet code="AppletTestSigned.class" archive="XslowXAppletTestSigned.jar" codebase="." width="100" height="100">
+    <param name="key1" value="value1">
+    <param name="key2" value="#value2">
+  </applet>
+</p>
+</body>
+</html>
diff -r 2a13d6d1b57c -r 14dcb4fb43ac tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.jnlp
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tests/jnlp_tests/signed/AppletTestSigned/resources/AppletTestSigned.jnlp	Wed Apr 18 12:28:08 2012 +0200
@@ -0,0 +1,63 @@
+<!--
+
+This file is part of IcedTea.
+
+IcedTea is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+IcedTea is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with IcedTea; see the file COPYING.  If not, write to the
+Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+02110-1301 USA.
+
+Linking this library statically or dynamically with other modules is
+making a combined work based on this library.  Thus, the terms and
+conditions of the GNU General Public License cover the whole
+combination.
+
+As a special exception, the copyright holders of this library give you
+permission to link this library with independent modules to produce an
+executable, regardless of the license terms of these independent
+modules, and to copy and distribute the resulting executable under
+terms of your choice, provided that you also meet, for each linked
+independent module, the terms and conditions of the license of that
+module.  An independent module is a module which is not derived from
+or based on this library.  If you modify this library, you may extend
+this exception to your version of the library, but you are not
+obligated to do so.  If you do not wish to do so, delete this
+exception statement from your version.
+
+ -->
+<?xml version="1.0" encoding="utf-8"?>
+<jnlp spec="1.0" href="AppletTestSigned.jnlp" codebase=".">
+    <information>
+        <title>SignedAppletTest</title>
+        <vendor>IcedTea</vendor>
+        <homepage href="http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Web "/>
+        <description>SignedAppletTest</description>
+        <offline/>
+    </information>
+    <resources>
+        <j2se version="1.4+"/>
+        <jar href="AppletTestSigned.jar"/>
+    </resources>
+    <applet-desc
+      documentBase="."
+      name="AppletTest"
+      main-class="AppletTestSigned"
+      width="100"
+      height="100">
+        <param name="key1" value="value1"/>
+        <param name="key2" value="value2"/>
+    </applet-desc>
+</jnlp>
+
+
+</applet-desc>
diff -r 2a13d6d1b57c -r 14dcb4fb43ac tests/jnlp_tests/signed/AppletTestSigned/srcs/AppletTestSigned.java
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tests/jnlp_tests/signed/AppletTestSigned/srcs/AppletTestSigned.java	Wed Apr 18 12:28:08 2012 +0200
@@ -0,0 +1,82 @@
+/* AppletTestSigned.java
+Copyright (C) 2012 Red Hat, Inc.
+
+This file is part of IcedTea.
+
+IcedTea is free software; you can redistribute it and/or
+modify it under the terms of the GNU General Public License as published by
+the Free Software Foundation, version 2.
+
+IcedTea is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with IcedTea; see the file COPYING.  If not, write to
+the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+02110-1301 USA.
+
+Linking this library statically or dynamically with other modules is
+making a combined work based on this library.  Thus, the terms and
+conditions of the GNU General Public License cover the whole
+combination.
+
+As a special exception, the copyright holders of this library give you
+permission to link this library with independent modules to produce an
+executable, regardless of the license terms of these independent
+modules, and to copy and distribute the resulting executable under
+terms of your choice, provided that you also meet, for each linked
+independent module, the terms and conditions of the license of that
+module.  An independent module is a module which is not derived from
+or based on this library.  If you modify this library, you may extend
+this exception to your version of the library, but you are not
+obligated to do so.  If you do not wish to do so, delete this
+exception statement from your version.
+ */
+
+import java.applet.Applet;
+
+public class AppletTestSigned extends Applet {
+
+    private class Killer extends Thread {
+
+        public int n = 2000;
+
+        @Override
+        public void run() {
+            try {
+                Thread.sleep(n);
+                System.out.println("AppletTestSigned killing himself after " + n + " ms of life");
+                System.exit(0);
+            } catch (Exception ex) {
+            }
+        }
+    }
+    private Killer killer;
+
+    @Override
+    public void init() {
+        System.out.println("AppletTestSigned was initialised");
+        killer = new Killer();
+    }
+
+    @Override
+    public void start() {
+        System.out.println("AppletTestSigned was started");
+        System.out.println(getParameter("key1"));
+        System.out.println(getParameter("key2"));
+        killer.start();
+        System.out.println("killer was started");
+    }
+
+    @Override
+    public void stop() {
+        System.out.println("AppletTestSigned was stopped");
+    }
+
+    @Override
+    public void destroy() {
+        System.out.println("AppletTestSigned will be destroyed");
+    }
+}
diff -r 2a13d6d1b57c -r 14dcb4fb43ac tests/jnlp_tests/signed/AppletTestSigned/testcases/AppletTestSignedTests.java
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tests/jnlp_tests/signed/AppletTestSigned/testcases/AppletTestSignedTests.java	Wed Apr 18 12:28:08 2012 +0200
@@ -0,0 +1,99 @@
+/* AppletTestSignedTests.java
+Copyright (C) 2012 Red Hat, Inc.
+
+This file is part of IcedTea.
+
+IcedTea is free software; you can redistribute it and/or
+modify it under the terms of the GNU General Public License as published by
+the Free Software Foundation, version 2.
+
+IcedTea is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with IcedTea; see the file COPYING.  If not, write to
+the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+02110-1301 USA.
+
+Linking this library statically or dynamically with other modules is
+making a combined work based on this library.  Thus, the terms and
+conditions of the GNU General Public License cover the whole
+combination.
+
+As a special exception, the copyright holders of this library give you
+permission to link this library with independent modules to produce an
+executable, regardless of the license terms of these independent
+modules, and to copy and distribute the resulting executable under
+terms of your choice, provided that you also meet, for each linked
+independent module, the terms and conditions of the license of that
+module.  An independent module is a module which is not derived from
+or based on this library.  If you modify this library, you may extend
+this exception to your version of the library, but you are not
+obligated to do so.  If you do not wish to do so, delete this
+exception statement from your version.
+ */
+
+import java.util.Arrays;
+import java.util.Collections;
+import java.util.List;
+import net.sourceforge.jnlp.ServerAccess;
+import net.sourceforge.jnlp.ServerAccess.ProcessResult;
+import org.junit.Assert;
+
+import org.junit.Test;
+
+public class AppletTestSignedTests {
+
+    private static ServerAccess server = new ServerAccess();
+    private final List<String> l = Collections.unmodifiableList(Arrays.asList(new String[]{"-Xtrustall"}));
+
+    @Test
+    public void AppletTestSignedTest() throws Exception {
+        System.out.println("connecting AppletTestSigned request");
+        System.err.println("connecting AppletTestSigned request");
+        ServerAccess.ProcessResult pr = server.executeJavawsHeadless(l, "/AppletTestSigned.jnlp");
+        System.out.println(pr.stdout);
+        System.err.println(pr.stderr);
+        evaluateSignedApplet(pr);
+        Assert.assertFalse(pr.wasTerminated);
+        Assert.assertEquals((Integer) 0, pr.returnValue);
+    }
+
+    private void evaluateSignedApplet(ProcessResult pr) {
+        String s3 = "AppletTestSigned was initialised";
+        Assert.assertTrue("AppletTestSigned stdout should contain " + s3 + " but didn't", pr.stdout.contains(s3));
+        String s0 = "AppletTestSigned was started";
+        Assert.assertTrue("AppletTestSigned stdout should contain " + s0 + " but didn't", pr.stdout.contains(s0));
+        String s1 = "value1";
+        Assert.assertTrue("AppletTestSigned stdout should contain " + s1 + " but didn't", pr.stdout.contains(s1));
+        String s2 = "value2";
+        Assert.assertTrue("AppletTestSigned stdout should contain " + s2 + " but didn't", pr.stdout.contains(s2));
+        String s4 = "AppletTestSigned was stopped";
+        Assert.assertFalse("AppletTestSigned stdout shouldn't contain " + s4 + " but did", pr.stdout.contains(s4));
+        String s5 = "AppletTestSigned will be destroyed";
+        Assert.assertFalse("AppletTestSigned stdout shouldn't contain " + s5 + " but did", pr.stdout.contains(s5));
+        String ss = "xception";
+        Assert.assertFalse("AppletTestSigned stderr should not contain " + ss + " but did", pr.stderr.contains(ss));
+        String s7 = "AppletTestSigned killing himself after 2000 ms of life";
+        Assert.assertTrue("AppletTestSigned stdout should contain " + s7 + " but didn't", pr.stdout.contains(s7));
+    }
+
+    @Test
+    public void AppletTestSignedFirefoxTest() throws Exception {
+        System.out.println("connecting AppletTestSigned in firefox request");
+        System.err.println("connecting AppletTestSigned in firefox request");
+        ServerAccess.PROCESS_TIMEOUT = 30 * 1000;
+        try {
+            ServerAccess.ProcessResult pr = server.executeBrowser("/AppletTestSigned.html");
+            System.out.println(pr.stdout);
+            System.err.println(pr.stderr);
+            evaluateSignedApplet(pr);
+            Assert.assertTrue(pr.wasTerminated);
+            //Assert.assertEquals((Integer) 0, pr.returnValue); due to destroy is null
+        } finally {
+            ServerAccess.PROCESS_TIMEOUT = 20 * 1000; //back to normal
+        }
+    }
+}


From ptisnovs at icedtea.classpath.org  Wed Apr 18 06:08:18 2012
From: ptisnovs at icedtea.classpath.org (ptisnovs at icedtea.classpath.org)
Date: Wed, 18 Apr 2012 13:08:18 +0000
Subject: /hg/gfx-test: * src/org/gfxtest/testsuites/ClippingPathByRectang...
Message-ID: <hg.7adf78a0fba2.1334754498.-6248649288953172555@icedtea.classpath.org>

changeset 7adf78a0fba2 in /hg/gfx-test
details: http://icedtea.classpath.org/hg/gfx-test?cmd=changeset;node=7adf78a0fba2
author: Pavel Tisnovsky <ptisnovs at redhat.com>
date: Wed Apr 18 15:10:50 2012 +0200

	* src/org/gfxtest/testsuites/ClippingPathByRectangleArea.java:
		Added new tests to this test suite.


diffstat:

 ChangeLog                                                   |    5 +
 src/org/gfxtest/testsuites/ClippingPathByRectangleArea.java |  462 +++++++++++-
 2 files changed, 465 insertions(+), 2 deletions(-)

diffs (truncated from 505 to 500 lines):

diff -r 2bd442a17073 -r 7adf78a0fba2 ChangeLog
--- a/ChangeLog	Tue Apr 17 14:37:07 2012 +0200
+++ b/ChangeLog	Wed Apr 18 15:10:50 2012 +0200
@@ -1,3 +1,8 @@
+2012-04-18  Pavel Tisnovsky  <ptisnovs at redhat.com>
+
+	* src/org/gfxtest/testsuites/ClippingPathByRectangleArea.java:
+	Added new tests to this test suite.
+
 2012-04-17  Pavel Tisnovsky  <ptisnovs at redhat.com>
 
 	* src/org/gfxtest/reporter/Reporter.java:
diff -r 2bd442a17073 -r 7adf78a0fba2 src/org/gfxtest/testsuites/ClippingPathByRectangleArea.java
--- a/src/org/gfxtest/testsuites/ClippingPathByRectangleArea.java	Tue Apr 17 14:37:07 2012 +0200
+++ b/src/org/gfxtest/testsuites/ClippingPathByRectangleArea.java	Wed Apr 18 15:10:50 2012 +0200
@@ -74,6 +74,8 @@
 @Zoom(1)
 public class ClippingPathByRectangleArea extends GfxTest
 {
+    private static final float[] DOTTED_PATTERN = new float[] {1,40};
+
     /**
      * Prepare canvas for the rendering.
      *
@@ -1110,7 +1112,7 @@
 
     /**
      * Check if line path could be clipped by a rectangle area. Path is rendered
-     * using dotted stroke paint with normal stroke width and using round cap style.
+     * using dotted stroke paint with normal stroke width.
      * 
      * @param image
      *            work image
@@ -1125,7 +1127,7 @@
         // set stroke width
         //CommonRenderingStyles.setStrokeThickWidth(graphics2d, BasicStroke.CAP_ROUND);
         // set dashed pattern
-        CommonRenderingStyles.setDashedStrokePattern(graphics2d, new float[] {1,20});
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
         // set clip region and draw the path
         drawLinePathClippedByRectangleArea(image, graphics2d);
         // test result
@@ -1133,6 +1135,462 @@
     }
 
     /**
+     * Check if quadratic path could be clipped by a rectangle area. Path is rendered
+     * using dotted stroke paint with normal stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipQuadraticPathByRectangleAreaDottedStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        //CommonRenderingStyles.setStrokeThickWidth(graphics2d, BasicStroke.CAP_ROUND);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawQuadraticPathClippedByRectangleArea(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if cubic path could be clipped by a rectangle area. Path is rendered
+     * using dotted stroke paint with normal stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipCubicPathByRectangleAreaDottedStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        //CommonRenderingStyles.setStrokeThickWidth(graphics2d, BasicStroke.CAP_ROUND);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawCubicPathClippedByRectangleArea(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if closed path could be clipped by a rectangle area. Path is rendered
+     * using dotted stroke paint with normal stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipClosedPathByRectangleAreaDottedStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        //CommonRenderingStyles.setStrokeThickWidth(graphics2d, BasicStroke.CAP_ROUND);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawClosedPathClippedByRectangleArea(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if crossed closed path could be clipped by a rectangle area. Path is rendered
+     * using dotted stroke paint with normal stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipCrossedClosedPathByRectangleAreaDottedStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        //CommonRenderingStyles.setStrokeThickWidth(graphics2d, BasicStroke.CAP_ROUND);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawCrossedClosedPathClippedByRectangleArea(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if line path could be clipped by a rectangle area. Path is rendered
+     * using dotted stroke paint with zero stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipLinePathByRectangleAreaDottedZeroStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeZeroThick(graphics2d);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawLinePathClippedByRectangleArea(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if quadratic path could be clipped by a rectangle area. Path is rendered
+     * using dotted stroke paint with zero stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipQuadraticPathByRectangleAreaDottedZeroStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeZeroThick(graphics2d);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawQuadraticPathClippedByRectangleArea(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if cubic path could be clipped by a rectangle area. Path is rendered
+     * using dotted stroke paint with zero stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipCubicPathByRectangleAreaDottedZeroStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeZeroThick(graphics2d);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawCubicPathClippedByRectangleArea(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if closed path could be clipped by a rectangle area. Path is rendered
+     * using dotted stroke paint with zero stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipClosedPathByRectangleAreaDottedZeroStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeZeroThick(graphics2d);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawClosedPathClippedByRectangleArea(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if crossed closed path could be clipped by a rectangle area. Path is rendered
+     * using dotted stroke paint with zero stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipCrossedClosedPathByRectangleAreaDottedZeroStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeZeroThick(graphics2d);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawCrossedClosedPathClippedByRectangleArea(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if line path could be clipped by a rectangle area. Path is rendered
+     * using dotted stroke paint with thick stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipLinePathByRectangleAreaDottedThickStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeThickWidth(graphics2d, BasicStroke.CAP_ROUND);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawLinePathClippedByRectangleArea(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if quadratic path could be clipped by a rectangle area. Path is rendered
+     * using dotted stroke paint with thick stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipQuadraticPathByRectangleAreaDottedThickStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeThickWidth(graphics2d, BasicStroke.CAP_ROUND);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawQuadraticPathClippedByRectangleArea(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if cubic path could be clipped by a rectangle area. Path is rendered
+     * using dotted stroke paint with thick stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipCubicPathByRectangleAreaDottedThickStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeThickWidth(graphics2d, BasicStroke.CAP_ROUND);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawCubicPathClippedByRectangleArea(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if closed path could be clipped by a rectangle area. Path is rendered
+     * using dotted stroke paint with thick stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipClosedPathByRectangleAreaDottedThickStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeThickWidth(graphics2d, BasicStroke.CAP_ROUND);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawClosedPathClippedByRectangleArea(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if crossed closed path could be clipped by a rectangle area. Path is rendered
+     * using dotted stroke paint with thick stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipCrossedClosedPathByRectangleAreaDottedThickStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeThickWidth(graphics2d, BasicStroke.CAP_ROUND);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawCrossedClosedPathClippedByRectangleArea(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if line path could be clipped by a rectangle area. Path is rendered
+     * using dotted stroke paint with extra thick stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipLinePathByRectangleAreaDottedExtraThickStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeExtraThickWidth(graphics2d, BasicStroke.CAP_ROUND);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawLinePathClippedByRectangleArea(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if quadratic path could be clipped by a rectangle area. Path is rendered
+     * using dotted stroke paint with extra thick stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipQuadraticPathByRectangleAreaDottedExtraThickStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeExtraThickWidth(graphics2d, BasicStroke.CAP_ROUND);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawQuadraticPathClippedByRectangleArea(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if cubic path could be clipped by a rectangle area. Path is rendered
+     * using dotted stroke paint with extra thick stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipCubicPathByRectangleAreaDottedExtraThickStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeExtraThickWidth(graphics2d, BasicStroke.CAP_ROUND);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawCubicPathClippedByRectangleArea(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if closed path could be clipped by a rectangle area. Path is rendered
+     * using dotted stroke paint with extra thick stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipClosedPathByRectangleAreaDottedExtraThickStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeExtraThickWidth(graphics2d, BasicStroke.CAP_ROUND);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawClosedPathClippedByRectangleArea(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if crossed closed path could be clipped by a rectangle area. Path is rendered
+     * using dotted stroke paint with extra thick stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipCrossedClosedPathByRectangleAreaDottedExtraThickStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeExtraThickWidth(graphics2d, BasicStroke.CAP_ROUND);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawCrossedClosedPathClippedByRectangleArea(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }


From ahughes at redhat.com  Wed Apr 18 06:14:35 2012
From: ahughes at redhat.com (Andrew Hughes)
Date: Wed, 18 Apr 2012 09:14:35 -0400 (EDT)
Subject: If Icedtea-web is the plug-in component for OpenJDK upstream,
	its	name should be openjdk-plugin !
In-Reply-To: <CACGw4H5-rer3_GPknwmi-k6g6ircNcogepiXD=3oJYHu2p_sdw@mail.gmail.com>
Message-ID: <f95ada75-5667-4044-bcee-d82a030fa959@zmail17.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> 
> 
> 
> On Tue, Apr 17, 2012 at 15:44, Deepak Bhole < dbhole at redhat.com >
> wrote:
> 
> 
> 
> No problem. For the record, I've opened a bug against yum:
> https://bugzilla.redhat.com/show_bug.cgi?id=813432
> Thanks!
> This is the first step towards a (partial) solution.
> 
> Of course, it'd be a universal solution if Icedtea-web would be
> integrated into OpenJDK or renamed OpenJDK-plugin. ;-)
> 

As has already been stated by Andrew Haley, the plugin was split apart
from the main IcedTea builds (packaged as java-1.x.x-openjdk) for technical
reasons, so integrating it into OpenJDK would be a backwards step that would
make things even worse than before.

This has far more effect on the end-user experience than getting the plugin
installed to begin with (a one-time effort).  Take the scenario that a bug
is found in the plugin.  There are three different processes by which the patch
could get out to end-users, depending on whether the plugin is independent,
part of IcedTea (as it was prior to March 2011) or part of OpenJDK.

1.  Plugin is independent
The patch is added to the source code base and a release made, which then gets
packaged for your favourite distribution.  The rebuild is trivial as the plugin
takes little time to build.  The impact on users is minimal as only those with
the plugin installed get an update and that update is only for the plugin.
This can all happen within the space of about a week (and that's mostly to give
everyone appropriate notice of the upcoming release).

2.  Plugin is part of IcedTea
The patch is added to the source code base, but making a release means making a new
release of IcedTea in its entirety.  Such a release has to be worthwhile for all
JDK users, not just plugin users.  It's more likely that the fix will be backported
to an existing release branch and a minor release made, to avoid a full major release
for just a plugin issue, but this still takes time and effects more people.  The
rebuild involves building the whole JDK again which takes about 30 minutes even on
fast x86_64 boxes, never mind other architectures like ARM.  All users get a JDK update
regardless of whether they use the plugin or not.  The amount of time this takes depends
on the current status of an IcedTea release, but it's very unlikely to be as quick as 1
in our experience.

3.  Plugin is part of OpenJDK
Any patches have to be contributed to Oracle under the OCA and approved by their engineers
to get into the 8 and 7 update trees rather than just our own tree.  The release cycle is
out of our control and determined by Oracle.  The rebuild and packaging process is much
the same as for 2.  Time taken is even more variable, as it depends on the OpenJDK release
cycle and availability of upstream approval, but much longer than for 1.

Hopefully, you can see from the above why we chose 1 in order to give our users fixes as
speedily as possible.  This long-time maintenance issue trumps initial install in terms
of ongoing user experience.

As to just renaming it "OpenJDK-plugin", we don't do this because it isn't part of OpenJDK,
and for much the same reasons "The GIMP" (which is a far worse name) isn't called "Photoshop"
and every fast food outlet isn't called "McDonalds", just because those names are more widely
recognisable.

Thanks for your feedback on the issues with installing the plugin and hopefully something can
be resolved in the packaging for Fedora.  This does seem to largely be a packaging issue, as
Debian and Gentoo both seem to handle this issue already, via "Recommends" and a post-dependency
respectively.

> Thanks again
> FC
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From ahughes at redhat.com  Wed Apr 18 06:23:43 2012
From: ahughes at redhat.com (Andrew Hughes)
Date: Wed, 18 Apr 2012 09:23:43 -0400 (EDT)
Subject: porting icedtea6 to FreeBSD
In-Reply-To: <20120417193540.GA15370@dormouse.experts-exchange.com>
Message-ID: <1a99cebe-96a1-4b45-803c-990ad0a81e36@zmail17.collab.prod.int.phx2.redhat.com>

----- Original Message -----
> On Tue, Apr 17, 2012 at 08:08:43AM -0700, Jason Helfman thus spake:
> >On Tue, Apr 17, 2012 at 7:56 AM, Andrew Hughes <ahughes at redhat.com>
> >wrote:
> >
> >> ----- Original Message -----
> >> >
> >> >
> >> >
> >> > On Tue, Apr 17, 2012 at 4:51 AM, Andrew Hughes <
> >> > ahughes at redhat.com >
> >> > wrote:
> >> >
> >> >
> >> >
> >> > ----- Original Message -----
> >> > > On Mon, Apr 16, 2012 at 09:59:00AM -0400, Andrew Hughes thus
> >> > > spake:
> >> > > >> Any thoughts on any of this?
> >> > > >> Thanks, again.
> >> > > >>
> >> > > >> -jgh
> >> > > >
> >> > > >What are you doing here?
> >> > > >
> >> > > >/usr/bin/sed -i.bak -e 's|--dry-run||g'
> >> > >
> >> >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.am
> >> > >
> >> >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.in
> >> > > >/usr/bin/sed -i.bak -e 's|--check|-q|g'
> >> > >
> >> >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.am
> >> > >
> >> >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.in
> >> > > >
> >> > > >If you're removing --dry-run, you're going to be applying the
> >> > > >patch
> >> > > >twice, which is why it's failing.
> >> > > >--
> >> > > >Andrew :)
> >> > >
> >> > > I've modified this to test the patch which in FreeBSD is the
> >> > > "-C"
> >> > > switch,
> >> > > and the "-q" is for SHASUM's to only output the hash.
> >> > >
> >> > > I was able to get much further in the build! Any thoughts on
> >> > > why
> >> > > this
> >> > > patch
> >> > > was seen as already applied?
> >> > >
> >> >
> >> > Because the build tests the patch, then applies it if that
> >> > passes. If
> >> > you
> >> > removed --dry-run from the first invocation and didn't replace
> >> > it
> >> > with -C,
> >> > you'd be applying the patch twice instead.
> >> >
> >> >
> >> >
> >> > That is what I have done, though. --dry-run is being replaced
> >> > with -C
> >> > in the build.
> >> > Is something else showing up?
> >> >
> >> > -jgh
> >> >
> >> >
> >>
> >> And it's still failing in the same way?  I thought you said you'd
> >> got much
> >> further... :-S
> >> --
> >> Andrew :)
> >>
> >
> >Yes, it is failing in the same way but much further into the build.
> >Initially, it would fail at the first/second patch.
> >I attached the latest buildlog to my email last night. It should
> >show the
> >issue, and with what patch the problem
> >was with.
> >
> >-jgh
> 
> I believe I found part of the issue. In the patchset, the file
> openjdk/7034464-hugepage.patch has a number of repatched instances
> within
> os_linux.cpp, which is more than likely the cause of this issue. It
> is being
> patched twice.
> 
> Starting at line 40, and another starting at line 209.
> 
> For instance, both are adding this information to the same file:
> 
> 47 +// Define MAP_HUGETLB here so we can build HotSpot on old
> systems.
> 48 +#ifndef MAP_HUGETLB
> 49 +#define MAP_HUGETLB 0x40000
> 50 +#endif
> 
> 227 +// Define MAP_HUGETLB here so we can build HotSpot on old
> systems.
> 228 +#ifndef MAP_HUGETLB
> 229 +#define MAP_HUGETLB 0x40000
> 230 +#endif
> 
> -jgh
> 
> --
> Jason Helfman         | FreeBSD Committer
> jgh at FreeBSD.org       | http://people.freebsd.org/~jgh
> 

Ah right, now that's more helpful :-)

It looks like the patch is a bit messed up, and BSD's patch program
is just not as tolerant as the GNU one.  My log shows this:

Checking patches/openjdk/7034464-hugepage.patch
Applying patches/openjdk/7034464-hugepage.patch
patching file openjdk/hotspot/src/os/linux/vm/globals_linux.hpp
patching file openjdk/hotspot/src/os/linux/vm/os_linux.cpp
patching file openjdk/hotspot/src/os/linux/vm/os_linux.cpp.orig
patching file openjdk/hotspot/src/os/linux/vm/os_linux.hpp
Checking patches/openjdk/7037939-hugepage.patch
Applying patches/openjdk/7037939-hugepage.patch
patching file openjdk/hotspot/src/os/linux/vm/os_linux.cpp
Hunk #1 succeeded at 4148 (offset -22 lines).
patching file openjdk/hotspot/src/os/solaris/vm/os_solaris.cpp
Hunk #2 succeeded at 5041 (offset -2 lines).
Checking patches/openjdk/7043564-hugepage.patch
Applying patches/openjdk/7043564-hugepage.patch
patching file openjdk/hotspot/src/os/linux/vm/os_linux.cpp
Hunk #1 succeeded at 5084 (offset 2234 lines).

I'll look at fixing this up in HEAD, but for BSD you can just disabled these
three by deleting the references from Makefile.am.
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From jvanek at redhat.com  Wed Apr 18 07:12:35 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Wed, 18 Apr 2012 16:12:35 +0200
Subject: Fwd: Re: [rfc][icedtea-web] reproducer for PR905
In-Reply-To: <4F7C5DC1.2030502@redhat.com>
References: <4F7C4F16.3000802@redhat.com> <4F7C5DC1.2030502@redhat.com>
Message-ID: <4F8ECBD3.1060207@redhat.com>

On 04/04/2012 04:42 PM, Jiri Vanek wrote:
>>>
>>> This reproducer is representing pr905 behaviour. All the tests except
>>> signed jar with parametrised archive are passing, which is correct, and
>>> the failing test is representing the issue.
>>>
......snip
   All issues mentioned here should be fixed in new patch
Especially fixed vendor/homepage of tests, unified ?test=..., and using of already pushed signed 
applet test
......snip
>> + @Test
>> + public void parametrizedAppletJavawsTest2() throws Exception {
>> + System.out.println("connecting ParametrizedJarAppletUrl2 request");
>> + System.err.println("connecting ParametrizedJarAppletUrl2 request");
>> + ServerAccess.ProcessResult pr = server.executeJavawsHeadless(null,
>> "/ParametrizedJarAppletUrl2.jnlp?time=123456");
>>
>> This is supposed to simulate running 'javaws ParametrizedJarAppletUrl2.jnlp?time=123456', right?
>> Well this is strange because if I run this command from terminal, I get the following:
>>
>> $ cd ./icedtea-web/build/tests.build/jnlp_test_server
>> $ javaws ParametrizedJarAppletUrl2.jnlp?time=123456
>> netx: Invalid jnlp file ParametrizedJarAppletUrl2.jnlp?time=123456
>>
>> I hope I'm misunderstanding the purpose of the above test (and the others similar to it) but if this
>> is the point, then something very strange is happening! Could you clarify what the above test is
>> supposed to simulate?
>
> Yes I can :) You must run it as url :) eg javaws
> http://localhost:44321/ParametrizedJarAppletUrl2.jnlp?time=123456
>
> Then everything behind ? is translated as parameter for server.
>
> If you are launching it as you are, then it is considered to be file, where question mark have no
> special meaning;)
>>

changelog:

2012-04-18  Jiri Vanek  <jvanek at redhat.com>

	Added tests for PR905 - parameters in jnlp/html application/applet resources
	* tests/jnlp_tests/simple/AppletTest/testcases/AppletTestTests.java:
	fixed reference to PROCESS_TIMEOUT by class instead by reference
	* tests/jnlp_tests/simple/ParametrizedJarUrl/resources/ParametrizedJarUrl.html:
	html file to launch applet, requested archive jar have parameter
	* tests/jnlp_tests/simple/ParametrizedJarUrl/resources/ParametrizedJarUrl1.jnlp:
	jnlp file to launch application, requested archive jar have parameter
	* tests/jnlp_tests/simple/ParametrizedJarUrl/resources/ParametrizedJarUrl2.jnlp:
	jnlp file to launch application, requested jnlp have parameter
	* tests/jnlp_tests/simple/ParametrizedJarUrl/resources/ParametrizedJarUrlSigned.html:
	html file to launch signed applet, requested archive jar have parameter
	* tests/jnlp_tests/simple/ParametrizedJarUrl/resources/ParametrizedJarUrlSigned1.jnlp:
	jnlp file to launch signed application, requested archive jar have parameter
	* tests/jnlp_tests/simple/ParametrizedJarUrl/resources/ParametrizedJarUrlSigned2.jnlp:
	jnlp file to launch signed application, requested jnlp have parameter
	* tests/jnlp_tests/simple/ParametrizedJarUrl/resources/ParametrizedJarAppletUrl2.jnlp
	* tests/jnlp_tests/simple/ParametrizedJarUrl/resources/ParametrizedJarAppletUrl.jnlp
	* tests/jnlp_tests/simple/ParametrizedJarUrl/resources/ParametrizedJarAppletUrlSigned2.jnlp
	* tests/jnlp_tests/simple/ParametrizedJarUrl/resources/ParametrizedJarAppletUrlSigned.jnlp
	variations launching applets from jnlp
	* tests/jnlp_tests/simple/ParametrizedJarUrl/testcases/ParametrizedJarUrlTests.java:
	testaceses of above ParametrizedJarUrl/jnlps+htmls namely - (parametrizedAppletTestSignedTest)
	, (testParametrizedJarUrl2), (testParametrizedJarUrlSigned2): passing
	calls /partially/ with parameter. Those test are passing.
	(parametrizedAppletTestSignedFirefoxTest) call with parameter upon signed
	applet in browser, failing and so is representing PR905

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr905reproducer3.diff
Type: text/x-patch
Size: 41903 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120418/debd084a/pr905reproducer3.diff 

From dbhole at redhat.com  Wed Apr 18 07:20:29 2012
From: dbhole at redhat.com (Deepak Bhole)
Date: Wed, 18 Apr 2012 10:20:29 -0400
Subject: [RFC][icedtea-web][JarCertVerifier Update] Remove/update useless
	variables
In-Reply-To: <4F7E05B0.5040901@redhat.com>
References: <4F7E05B0.5040901@redhat.com>
Message-ID: <20120418142028.GT14177@redhat.com>

* Danesh Dadachanji <ddadacha at redhat.com> [2012-04-05 16:52]:
> Hi,
> 
> When going through updates for JarCertVerifier, I stumbled across
> these to variables that don't serve much purpose. The two
> ArrayLists, verifiedJars and unverifiedJars contain the jars passed
> into JarCertVerifier that are either verified or unverified.
> However, the lists' contents are never read, except for in
> allJarsSigned().
> 
> To clarify, verifiedJars is never touched apart from declaration and
> adding contents so I propose we remove its unnecessary code
> altogether. Secondly, apart from initialization and adding contents,
> unverifiedJars is only read by the method mentioned above to check
> its size, let alone examine its contents. Since this is the case, an
> integer be a better fit for this variable. The attached patch does
> this.
> 
> I could not find them being read anywhere outside of JarCertVerifier
> so I think these changes should be acceptable. What does everyone
> else think?
> 

Looks fine to me. OK for HEAD.

Deepak

> ChangeLog:
> +2012-04-05  Danesh Dadachanji  <ddadacha at redhat.com>
> +
> +	Update useless variables in JarCertVerifier.
> +	* netx/net/sourceforge/jnlp/tools/JarCertVerifier.java:
> +	Removed verifiedJars list, renamed unverifiedJars to numUnverifiedJars
> +	and changed its type to int instead of ArrayList.
> +
> 
> 
> Cheers,
> Danesh

> diff --git a/netx/net/sourceforge/jnlp/tools/JarCertVerifier.java b/netx/net/sourceforge/jnlp/tools/JarCertVerifier.java
> --- a/netx/net/sourceforge/jnlp/tools/JarCertVerifier.java
> +++ b/netx/net/sourceforge/jnlp/tools/JarCertVerifier.java
> @@ -89,11 +89,8 @@ public class JarCertVerifier implements 
>  
>      private boolean anyJarsSigned = false;
>  
> -    /** all of the jar files that were verified */
> -    private ArrayList<String> verifiedJars = null;
> -
> -    /** all of the jar files that were not verified */
> -    private ArrayList<String> unverifiedJars = null;
> +    /** Number of the jar files that were not verified */
> +    private int numUnverifiedJars = 0;
>  
>      /** the certificates used for jar verification */
>      private HashMap<CertPath, Integer> certs = new HashMap<CertPath, Integer>();
> @@ -180,8 +177,7 @@ public class JarCertVerifier implements 
>      public void verifyJars(List<JARDesc> jars, ResourceTracker tracker)
>              throws Exception {
>  
> -        verifiedJars = new ArrayList<String>();
> -        unverifiedJars = new ArrayList<String>();
> +        numUnverifiedJars = 0;
>  
>          for (int i = 0; i < jars.size(); i++) {
>  
> @@ -201,12 +197,9 @@ public class JarCertVerifier implements 
>                  verifyResult result = verifyJar(localFile);
>  
>                  if (result == verifyResult.UNSIGNED) {
> -                    unverifiedJars.add(localFile);
> +                    numUnverifiedJars++;
>                  } else if (result == verifyResult.SIGNED_NOT_OK) {
>                      noSigningIssues = false;
> -                    verifiedJars.add(localFile);
> -                } else if (result == verifyResult.SIGNED_OK) {
> -                    verifiedJars.add(localFile);
>                  }
>              } catch (Exception e) {
>                  // We may catch exceptions from using verifyJar()
> @@ -549,7 +542,7 @@ public class JarCertVerifier implements 
>       * @return True if all jars are signed, false if there are one or more unsigned jars
>       */
>      public boolean allJarsSigned() {
> -        return this.unverifiedJars.size() == 0;
> +        return numUnverifiedJars == 0;
>      }
>  
>  }



From omajid at redhat.com  Wed Apr 18 07:57:06 2012
From: omajid at redhat.com (Omair Majid)
Date: Wed, 18 Apr 2012 10:57:06 -0400
Subject: [icedtea-web] RFC: PR918: java applet windows uses a low resulution
	black/white icon
Message-ID: <4F8ED642.30808@redhat.com>

Hi,

The attached patch fixes PR918 [1] by removing the code the set the
icons for all top-level windows. Any windows created by an applet/jnlp
application should now get the default java icon if they dont set an
icon explicitly. The patch also sets the icons for all the top-level
windows we create explicitly to the default application icon (currently
netx's icon).

We probably want to change the application icon from netx-icon.png to
something else too, but I plan to tackle that as a separate issue (do we
even have an icedtea-web icon?)

Any thoughts or comments?

Thanks,
Omair

[1] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=918
-------------- next part --------------
A non-text attachment was scrubbed...
Name: let-programs-have-default-icons-01.patch
Type: text/x-patch
Size: 17412 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120418/71d3db70/let-programs-have-default-icons-01.patch 

From ptisnovs at icedtea.classpath.org  Wed Apr 18 08:42:03 2012
From: ptisnovs at icedtea.classpath.org (ptisnovs at icedtea.classpath.org)
Date: Wed, 18 Apr 2012 15:42:03 +0000
Subject: /hg/release/icedtea6-1.10: Backport of: 6792400: Avoid loading o...
Message-ID: <hg.4515e31b48fa.1334763723.-53431993501496596@icedtea.classpath.org>

changeset 4515e31b48fa in /hg/release/icedtea6-1.10
details: http://icedtea.classpath.org/hg/release/icedtea6-1.10?cmd=changeset;node=4515e31b48fa
author: ptisnovs
date: Wed Apr 18 18:41:40 2012 +0200

	Backport of: 6792400: Avoid loading of Normalizer resources for simple uses


diffstat:

 ChangeLog                                                        |   8 +
 Makefile.am                                                      |   3 +-
 NEWS                                                             |   2 +
 patches/openjdk/6792400-Avoid_loading_Normalizer_resources.patch |  49 ++++++++++
 4 files changed, 61 insertions(+), 1 deletions(-)

diffs (94 lines):

diff -r 182bdaba43ea -r 4515e31b48fa ChangeLog
--- a/ChangeLog	Tue Apr 17 18:57:20 2012 +0200
+++ b/ChangeLog	Wed Apr 18 18:41:40 2012 +0200
@@ -1,3 +1,11 @@
+2012-04-18  Pavel Tisnovsky  <ptisnovs at redhat.com>
+
+	* patches/openjdk/6792400-Avoid_loading_Normalizer_resources.patch:
+	Backport of: 6792400: Avoid loading of Normalizer resources
+	for simple uses
+	* NEWS: Mention backport.
+	* Makefile.am: Updated
+
 2012-04-17  Pavel Tisnovsky  <ptisnovs at redhat.com>
 
 	PR881: Sign tests (wsse.policy.basic) failures with OpenJDK6
diff -r 182bdaba43ea -r 4515e31b48fa Makefile.am
--- a/Makefile.am	Tue Apr 17 18:57:20 2012 +0200
+++ b/Makefile.am	Wed Apr 18 18:41:40 2012 +0200
@@ -380,7 +380,8 @@
 	patches/openjdk/7103725-ssl_beast_regression.patch \
 	patches/openjdk/6851973-kerberos.patch \
 	patches/openjdk/7091528-javadoc_class_files.patch \
-	patches/idresolver_fix.patch
+	patches/idresolver_fix.patch \
+	patches/openjdk/6792400-Avoid_loading_Normalizer_resources.patch
 
 if WITH_ALT_HSBUILD
 ICEDTEA_PATCHES += \
diff -r 182bdaba43ea -r 4515e31b48fa NEWS
--- a/NEWS	Tue Apr 17 18:57:20 2012 +0200
+++ b/NEWS	Wed Apr 18 18:41:40 2012 +0200
@@ -13,6 +13,8 @@
 * Bug fixes
   - PR732: Use xsltproc for bootstrap xslt in place of Xerces/Xalan
   - PR881: Sign tests (wsse.policy.basic) failures with OpenJDK6
+* Backports
+  - S6792400: Avoid loading of Normalizer resources for simple uses
 
 New in release 1.10.6 (2012-02-14):
 
diff -r 182bdaba43ea -r 4515e31b48fa patches/openjdk/6792400-Avoid_loading_Normalizer_resources.patch
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/patches/openjdk/6792400-Avoid_loading_Normalizer_resources.patch	Wed Apr 18 18:41:40 2012 +0200
@@ -0,0 +1,50 @@
+# HG changeset patch
+# User peytoia
+# Date 1245934539 -32400
+# Node ID e0707baa159364ff923bf901eab1b6c83d4cf092
+# Parent  4d54d6e7bcefd16bcc9a26b93937359f031389ca
+6792400: Avoid loading of Normalizer resources for simple uses
+Reviewed-by: okutsu
+
+diff -r 4d54d6e7bcef -r e0707baa1593 src/share/classes/sun/text/normalizer/NormalizerBase.java
+--- openjdk/jdk/src/share/classes/sun/text/normalizer/NormalizerBase.java	Thu Jun 25 02:42:26 2009 -0700
++++ openjdk/jdk/src/share/classes/sun/text/normalizer/NormalizerBase.java	Thu Jun 25 21:55:39 2009 +0900
+@@ -1598,15 +1598,34 @@
+      * @param options   the optional features to be enabled.
+      */
+     public static String normalize(String str, Normalizer.Form form, int options) {
++        int len = str.length();
++        boolean asciiOnly = true;
++        if (len < 80) {
++            for (int i = 0; i < len; i++) {
++                if (str.charAt(i) > 127) {
++                    asciiOnly = false;
++                    break;
++                }
++            }
++        } else {
++            char[] a = str.toCharArray();
++            for (int i = 0; i < len; i++) {
++                if (a[i] > 127) {
++                    asciiOnly = false;
++                    break;
++                }
++            }
++        }
++
+         switch (form) {
+         case NFC :
+-            return NFC.normalize(str, options);
++            return asciiOnly ? str : NFC.normalize(str, options);
+         case NFD :
+-            return NFD.normalize(str, options);
++            return asciiOnly ? str : NFD.normalize(str, options);
+         case NFKC :
+-            return NFKC.normalize(str, options);
++            return asciiOnly ? str : NFKC.normalize(str, options);
+         case NFKD :
+-            return NFKD.normalize(str, options);
++            return asciiOnly ? str : NFKD.normalize(str, options);
+         }
+ 
+         throw new IllegalArgumentException("Unexpected normalization form: " +


From jvanek at redhat.com  Wed Apr 18 08:46:48 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Wed, 18 Apr 2012 17:46:48 +0200
Subject: [icedtea-web] RFC: PR918: java applet windows uses a low
	resulution black/white icon
In-Reply-To: <4F8ED642.30808@redhat.com>
References: <4F8ED642.30808@redhat.com>
Message-ID: <4F8EE1E8.5070504@redhat.com>

On 04/18/2012 04:57 PM, Omair Majid wrote:
> Hi,

Hi!

Walking through the patch, but I will reply tomorrow after full exploration.
>
> The attached patch fixes PR918 [1] by removing the code the set the
> icons for all top-level windows. Any windows created by an applet/jnlp
> application should now get the default java icon if they dont set an
> icon explicitly. The patch also sets the icons for all the top-level
> windows we create explicitly to the default application icon (currently
> netx's icon).
>
> We probably want to change the application icon from netx-icon.png to
> something else too, but I plan to tackle that as a separate issue (do we
> even have an icedtea-web icon?)
>
> Any thoughts or comments?
>
Yap  O:) - after first look the usage of Nx icon have terrified me :) [nothing personal, it is just 
small and nasty;)

Just hint for icon - IMHO it should bee  similar to splash screen. On one side i can re factor 
splash screen design to match new icon. On second new icon can be inspired by splash screen.
so 16x16 I and W letters, some color matches
    32x32 IcedTea-web as my small splashscreen is designed
    64x64 Just shrunken splashscreen - full colours and leafs

This sizes are just idea, and your ImageResources can provide small x medium x large icon as desired 
by moment and situation.

> Thanks,
> Omair
>
> [1] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=918



From ptisnovs at icedtea.classpath.org  Wed Apr 18 08:47:48 2012
From: ptisnovs at icedtea.classpath.org (ptisnovs at icedtea.classpath.org)
Date: Wed, 18 Apr 2012 15:47:48 +0000
Subject: /hg/release/icedtea6-1.11: Backport of: 6792400: Avoid loading o...
Message-ID: <hg.d1bcc17048f3.1334764068.-53431993501496595@icedtea.classpath.org>

changeset d1bcc17048f3 in /hg/release/icedtea6-1.11
details: http://icedtea.classpath.org/hg/release/icedtea6-1.11?cmd=changeset;node=d1bcc17048f3
author: ptisnovs
date: Wed Apr 18 18:47:34 2012 +0200

	Backport of: 6792400: Avoid loading of Normalizer resources for simple uses


diffstat:

 ChangeLog                                                        |   8 +
 Makefile.am                                                      |   3 +-
 NEWS                                                             |   2 +
 patches/openjdk/6792400-Avoid_loading_Normalizer_resources.patch |  49 ++++++++++
 4 files changed, 61 insertions(+), 1 deletions(-)

diffs (94 lines):

diff -r 16896bd9ecbc -r d1bcc17048f3 ChangeLog
--- a/ChangeLog	Tue Apr 17 19:00:05 2012 +0200
+++ b/ChangeLog	Wed Apr 18 18:47:34 2012 +0200
@@ -1,3 +1,11 @@
+2012-04-18  Pavel Tisnovsky  <ptisnovs at redhat.com>
+
+	* patches/openjdk/6792400-Avoid_loading_Normalizer_resources.patch:
+	Backport of: 6792400: Avoid loading of Normalizer resources
+	for simple uses
+	* NEWS: Mention backport.
+	* Makefile.am: Updated
+
 2012-04-17  Pavel Tisnovsky  <ptisnovs at redhat.com>
 
 	PR881: Sign tests (wsse.policy.basic) failures with OpenJDK6
diff -r 16896bd9ecbc -r d1bcc17048f3 Makefile.am
--- a/Makefile.am	Tue Apr 17 19:00:05 2012 +0200
+++ b/Makefile.am	Wed Apr 18 18:47:34 2012 +0200
@@ -417,7 +417,8 @@
 	patches/openjdk/7103725-ssl_beast_regression.patch \
 	patches/openjdk/7140882-dont-return-booleans-from-methods-returning-pointers.patch \
 	patches/openjdk/remove-mimpure-option-to-gcc.patch \
-	patches/idresolver_fix.patch
+	patches/idresolver_fix.patch \
+	patches/openjdk/6792400-Avoid_loading_Normalizer_resources.patch
 
 if WITH_RHINO
 ICEDTEA_PATCHES += \
diff -r 16896bd9ecbc -r d1bcc17048f3 NEWS
--- a/NEWS	Tue Apr 17 19:00:05 2012 +0200
+++ b/NEWS	Wed Apr 18 18:47:34 2012 +0200
@@ -15,6 +15,8 @@
 * Bug fixes
   - RH789154: javac error messages no longer contain the full path to the offending file:
   - PR881: Sign tests (wsse.policy.basic) failures with OpenJDK6
+* Backports
+  - S6792400: Avoid loading of Normalizer resources for simple uses
 
 New in release 1.11.1 (2012-02-14):
 
diff -r 16896bd9ecbc -r d1bcc17048f3 patches/openjdk/6792400-Avoid_loading_Normalizer_resources.patch
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/patches/openjdk/6792400-Avoid_loading_Normalizer_resources.patch	Wed Apr 18 18:47:34 2012 +0200
@@ -0,0 +1,50 @@
+# HG changeset patch
+# User peytoia
+# Date 1245934539 -32400
+# Node ID e0707baa159364ff923bf901eab1b6c83d4cf092
+# Parent  4d54d6e7bcefd16bcc9a26b93937359f031389ca
+6792400: Avoid loading of Normalizer resources for simple uses
+Reviewed-by: okutsu
+
+diff -r 4d54d6e7bcef -r e0707baa1593 src/share/classes/sun/text/normalizer/NormalizerBase.java
+--- openjdk/jdk/src/share/classes/sun/text/normalizer/NormalizerBase.java	Thu Jun 25 02:42:26 2009 -0700
++++ openjdk/jdk/src/share/classes/sun/text/normalizer/NormalizerBase.java	Thu Jun 25 21:55:39 2009 +0900
+@@ -1598,15 +1598,34 @@
+      * @param options   the optional features to be enabled.
+      */
+     public static String normalize(String str, Normalizer.Form form, int options) {
++        int len = str.length();
++        boolean asciiOnly = true;
++        if (len < 80) {
++            for (int i = 0; i < len; i++) {
++                if (str.charAt(i) > 127) {
++                    asciiOnly = false;
++                    break;
++                }
++            }
++        } else {
++            char[] a = str.toCharArray();
++            for (int i = 0; i < len; i++) {
++                if (a[i] > 127) {
++                    asciiOnly = false;
++                    break;
++                }
++            }
++        }
++
+         switch (form) {
+         case NFC :
+-            return NFC.normalize(str, options);
++            return asciiOnly ? str : NFC.normalize(str, options);
+         case NFD :
+-            return NFD.normalize(str, options);
++            return asciiOnly ? str : NFD.normalize(str, options);
+         case NFKC :
+-            return NFKC.normalize(str, options);
++            return asciiOnly ? str : NFKC.normalize(str, options);
+         case NFKD :
+-            return NFKD.normalize(str, options);
++            return asciiOnly ? str : NFKD.normalize(str, options);
+         }
+ 
+         throw new IllegalArgumentException("Unexpected normalization form: " +


From omajid at redhat.com  Wed Apr 18 08:55:37 2012
From: omajid at redhat.com (Omair Majid)
Date: Wed, 18 Apr 2012 11:55:37 -0400
Subject: [icedtea-web] RFC: PR918: java applet windows uses a low
	resulution black/white icon
In-Reply-To: <4F8EE1E8.5070504@redhat.com>
References: <4F8ED642.30808@redhat.com> <4F8EE1E8.5070504@redhat.com>
Message-ID: <4F8EE3F9.8030909@redhat.com>

Hi Jiri,

On 04/18/2012 11:46 AM, Jiri Vanek wrote:
> On 04/18/2012 04:57 PM, Omair Majid wrote:
> Walking through the patch, but I will reply tomorrow after full
> exploration.

Thanks in advance!

>>
>> The attached patch fixes PR918 [1] by removing the code the set the
>> icons for all top-level windows. Any windows created by an applet/jnlp
>> application should now get the default java icon if they dont set an
>> icon explicitly. The patch also sets the icons for all the top-level
>> windows we create explicitly to the default application icon (currently
>> netx's icon).
>>
>> We probably want to change the application icon from netx-icon.png to
>> something else too, but I plan to tackle that as a separate issue (do we
>> even have an icedtea-web icon?)
>>
>> Any thoughts or comments?
>>
> Yap  O:) - after first look the usage of Nx icon have terrified me :)
> [nothing personal, it is just small and nasty;)
> 

As I said, I am completely open to replacing it. The patch just makes
sure that the icon is only used for icedtea-web windows as opposed to
all windows by default.

> Just hint for icon - IMHO it should be similar to splash screen.

Yes, some sort of consistency would be great.

> On
> one side i can re factor splash screen design to match new icon. On
> second new icon can be inspired by splash screen.
> so 16x16 I and W letters, some color matches
>    32x32 IcedTea-web as my small splashscreen is designed
>    64x64 Just shrunken splashscreen - full colours and leafs
> 
> This sizes are just idea

I am not a graphics expert, so I will be okay with whatever new
size/shape the new icon takes (and whoever the new designer happens to
be ;) ).

> and your ImageResources can provide small x
> medium x large icon as desired by moment and situation.
> 

Yes, I can certainly modify ImageResources to take care of more sizes.

Cheers,
Omair


From jgh at FreeBSD.org  Wed Apr 18 09:21:36 2012
From: jgh at FreeBSD.org (Jason Helfman)
Date: Wed, 18 Apr 2012 09:21:36 -0700
Subject: porting icedtea6 to FreeBSD
In-Reply-To: <1a99cebe-96a1-4b45-803c-990ad0a81e36@zmail17.collab.prod.int.phx2.redhat.com>
References: <20120417193540.GA15370@dormouse.experts-exchange.com>
	<1a99cebe-96a1-4b45-803c-990ad0a81e36@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <20120418162136.GA96044@dormouse.experts-exchange.com>

On Wed, Apr 18, 2012 at 09:23:43AM -0400, Andrew Hughes thus spake:
>----- Original Message -----
>> On Tue, Apr 17, 2012 at 08:08:43AM -0700, Jason Helfman thus spake:
>> >On Tue, Apr 17, 2012 at 7:56 AM, Andrew Hughes <ahughes at redhat.com>
>> >wrote:
>> >
>> >> ----- Original Message -----
>> >> >
>> >> >
>> >> >
>> >> > On Tue, Apr 17, 2012 at 4:51 AM, Andrew Hughes <
>> >> > ahughes at redhat.com >
>> >> > wrote:
>> >> >
>> >> >
>> >> >
>> >> > ----- Original Message -----
>> >> > > On Mon, Apr 16, 2012 at 09:59:00AM -0400, Andrew Hughes thus
>> >> > > spake:
>> >> > > >> Any thoughts on any of this?
>> >> > > >> Thanks, again.
>> >> > > >>
>> >> > > >> -jgh
>> >> > > >
>> >> > > >What are you doing here?
>> >> > > >
>> >> > > >/usr/bin/sed -i.bak -e 's|--dry-run||g'
>> >> > >
>> >> >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.am
>> >> > >
>> >> >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.in
>> >> > > >/usr/bin/sed -i.bak -e 's|--check|-q|g'
>> >> > >
>> >> >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.am
>> >> > >
>> >> >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.in
>> >> > > >
>> >> > > >If you're removing --dry-run, you're going to be applying the
>> >> > > >patch
>> >> > > >twice, which is why it's failing.
>> >> > > >--
>> >> > > >Andrew :)
>> >> > >
>> >> > > I've modified this to test the patch which in FreeBSD is the
>> >> > > "-C"
>> >> > > switch,
>> >> > > and the "-q" is for SHASUM's to only output the hash.
>> >> > >
>> >> > > I was able to get much further in the build! Any thoughts on
>> >> > > why
>> >> > > this
>> >> > > patch
>> >> > > was seen as already applied?
>> >> > >
>> >> >
>> >> > Because the build tests the patch, then applies it if that
>> >> > passes. If
>> >> > you
>> >> > removed --dry-run from the first invocation and didn't replace
>> >> > it
>> >> > with -C,
>> >> > you'd be applying the patch twice instead.
>> >> >
>> >> >
>> >> >
>> >> > That is what I have done, though. --dry-run is being replaced
>> >> > with -C
>> >> > in the build.
>> >> > Is something else showing up?
>> >> >
>> >> > -jgh
>> >> >
>> >> >
>> >>
>> >> And it's still failing in the same way?  I thought you said you'd
>> >> got much
>> >> further... :-S
>> >> --
>> >> Andrew :)
>> >>
>> >
>> >Yes, it is failing in the same way but much further into the build.
>> >Initially, it would fail at the first/second patch.
>> >I attached the latest buildlog to my email last night. It should
>> >show the
>> >issue, and with what patch the problem
>> >was with.
>> >
>> >-jgh
>>
>> I believe I found part of the issue. In the patchset, the file
>> openjdk/7034464-hugepage.patch has a number of repatched instances
>> within
>> os_linux.cpp, which is more than likely the cause of this issue. It
>> is being
>> patched twice.
>>
>> Starting at line 40, and another starting at line 209.
>>
>> For instance, both are adding this information to the same file:
>>
>> 47 +// Define MAP_HUGETLB here so we can build HotSpot on old
>> systems.
>> 48 +#ifndef MAP_HUGETLB
>> 49 +#define MAP_HUGETLB 0x40000
>> 50 +#endif
>>
>> 227 +// Define MAP_HUGETLB here so we can build HotSpot on old
>> systems.
>> 228 +#ifndef MAP_HUGETLB
>> 229 +#define MAP_HUGETLB 0x40000
>> 230 +#endif
>>
>> -jgh
>>
>> --
>> Jason Helfman         | FreeBSD Committer
>> jgh at FreeBSD.org       | http://people.freebsd.org/~jgh
>>
>
>Ah right, now that's more helpful :-)
>
>It looks like the patch is a bit messed up, and BSD's patch program
>is just not as tolerant as the GNU one.  My log shows this:
>
>Checking patches/openjdk/7034464-hugepage.patch
>Applying patches/openjdk/7034464-hugepage.patch
>patching file openjdk/hotspot/src/os/linux/vm/globals_linux.hpp
>patching file openjdk/hotspot/src/os/linux/vm/os_linux.cpp
>patching file openjdk/hotspot/src/os/linux/vm/os_linux.cpp.orig
>patching file openjdk/hotspot/src/os/linux/vm/os_linux.hpp
>Checking patches/openjdk/7037939-hugepage.patch
>Applying patches/openjdk/7037939-hugepage.patch
>patching file openjdk/hotspot/src/os/linux/vm/os_linux.cpp
>Hunk #1 succeeded at 4148 (offset -22 lines).
>patching file openjdk/hotspot/src/os/solaris/vm/os_solaris.cpp
>Hunk #2 succeeded at 5041 (offset -2 lines).
>Checking patches/openjdk/7043564-hugepage.patch
>Applying patches/openjdk/7043564-hugepage.patch
>patching file openjdk/hotspot/src/os/linux/vm/os_linux.cpp
>Hunk #1 succeeded at 5084 (offset 2234 lines).
>
>I'll look at fixing this up in HEAD, but for BSD you can just disabled these
>three by deleting the references from Makefile.am.

Great, thanks. I don't see what to delete though. Would you mind sending a
diff?

Thanks,
Jason

-- 
Jason Helfman         | FreeBSD Committer
jgh at FreeBSD.org       | http://people.freebsd.org/~jgh


From jvanek at redhat.com  Wed Apr 18 09:32:04 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Wed, 18 Apr 2012 18:32:04 +0200
Subject: [icedtea-web] RFC: PR918: java applet windows uses a low
	resulution black/white icon
In-Reply-To: <4F8EE3F9.8030909@redhat.com>
References: <4F8ED642.30808@redhat.com> <4F8EE1E8.5070504@redhat.com>
	<4F8EE3F9.8030909@redhat.com>
Message-ID: <4F8EEC84.80900@redhat.com>

On 04/18/2012 05:55 PM, Omair Majid wrote:
> Hi Jiri,
>
> On 04/18/2012 11:46 AM, Jiri Vanek wrote:
>> On 04/18/2012 04:57 PM, Omair Majid wrote:
>> Walking through the patch, but I will reply tomorrow after full
>> exploration.
>
> Thanks in advance!
>
>>>
>>> The attached patch fixes PR918 [1] by removing the code the set the
>>> icons for all top-level windows. Any windows created by an applet/jnlp
>>> application should now get the default java icon if they dont set an
>>> icon explicitly. The patch also sets the icons for all the top-level
>>> windows we create explicitly to the default application icon (currently
>>> netx's icon).
>>>
>>> We probably want to change the application icon from netx-icon.png to
>>> something else too, but I plan to tackle that as a separate issue (do we
>>> even have an icedtea-web icon?)
>>>
>>> Any thoughts or comments?
>>>
>> Yap  O:) - after first look the usage of Nx icon have terrified me :)
>> [nothing personal, it is just small and nasty;)
>>
>
> As I said, I am completely open to replacing it. The patch just makes
> sure that the icon is only used for icedtea-web windows as opposed to
> all windows by default.
>
>> Just hint for icon - IMHO it should be similar to splash screen.
>
> Yes, some sort of consistency would be great.
>
>> On
>> one side i can re factor splash screen design to match new icon. On
>> second new icon can be inspired by splash screen.
>> so 16x16 I and W letters, some color matches
>>     32x32 IcedTea-web as my small splashscreen is designed
>>     64x64 Just shrunken splashscreen - full colours and leafs
>>
>> This sizes are just idea
>
> I am not a graphics expert, so I will be okay with whatever new
> size/shape the new icon takes (and whoever the new designer happens to
> be ;) ).
>
>> and your ImageResources can provide small x
>> medium x large icon as desired by moment and situation.
>>
>
> Yes, I can certainly modify ImageResources to take care of more sizes.

Then there rises question when to use which :)

Btw - why have you decided to discard netx icon as default one and use java's one as default for 
"users windows"?

In case icons will be little bit nicer, then it sounds to me like good idea to have this icons 
everywhere.
Can we determine if user ave specified his own? I' afraid we can not :-(


Just what I have seen for now:

You are using on everywhere new Imageresource().getApplicationImage()
It is not nice.

It should be static or singleton. My vote is for singleton. Both will allow caching, and singleton 
is "more object like".

the choice between ImageResources.getInstance().getApplicationImage() and 
ImageResources.getApplicationImage() is up to you but I do not like creating new ImageResources() 
with new icon every time.

Also considering on how much places you have to setIconImage(new 
ImageResources().getApplicationImage()); (or similar) I'm thinking about pack it somewhere. But I'm 
not sure how and where.
eg new ImageResources().iconizeMainWindows()?
or etleast eg new ImageResources().iconizeWindows(Window w)? (but only the first one looks like 
have sense if possible) And also such a "magical method" can be misleading for future developers.

Few more hints inline:




 > let-programs-have-default-icons-01.patch
 >
 >
 > diff --git a/ChangeLog b/ChangeLog
 > --- a/ChangeLog
 > +++ b/ChangeLog
 > @@ -1,3 +1,33 @@
 > +2012-04-18  Omair Majid<omajid at redhat.com>
 > +
 > +	PR918: java applet windows uses a low resulution black/white icon
 > +	* NEWS: Update with fix.
 > +	* netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java: Remove windowIcon.
 > +	(initialize): Do not call loadWindowIcon.
 > +	(getWindowIcon): Remove.
 > +	(setWindowIcon): Remove.
 > +	(loadWindowIcon): Remove.
 > +	* netx/net/sourceforge/jnlp/runtime/JNLPSecurityManager.java
 > +	(checkTopLevelWindow): Do not set the icon for all top level windows. Use
 > +	the default java icon instead.
 > +	* netx/net/sourceforge/jnlp/util/ImageResources.java: New file. Provides
 > +	access to icons.
 > +	* netx/net/sourceforge/jnlp/JNLPSplashScreen.java (JNLPSplashScreen),
 > +	* netx/net/sourceforge/jnlp/cache/DefaultDownloadIndicator.java
 > +	(getListener),
 > +	* netx/net/sourceforge/jnlp/controlpanel/AdvancedProxySettingsDialog.java
 > +	(AdvancedProxySettingsDialog),
 > +	* netx/net/sourceforge/jnlp/controlpanel/CacheViewer.java (CacheViewer),
 > +	* netx/net/sourceforge/jnlp/controlpanel/ControlPanel.java (ControlPanel),
 > +	* netx/net/sourceforge/jnlp/security/SecurityDialog.java (SecurityDialog),
 > +	* netx/net/sourceforge/jnlp/security/viewer/CertificateViewer.java
 > +	(CertificateViewer),
 > +	* netx/net/sourceforge/jnlp/util/BasicExceptionDialog.java (show),
 > +	* plugin/icedteanp/java/sun/applet/JavaConsole.java (initialize):
 > +	Explicitly load icons.
 > +	* tests/netx/unit/net/sourceforge/jnlp/util/ImageResourcesTest.java: Test
 > +	for ImageResources class.
 > +
 >   2012-04-18  Jiri Vanek<jvanek at redhat.com>
 >
 >   	Allowed signed applets in automatic reproducers tests
 > diff --git a/NEWS b/NEWS
 > --- a/NEWS
 > +++ b/NEWS
 > @@ -14,6 +14,8 @@
 >   * Plugin
 >     - PR820: IcedTea-Web 1.1.3 crashing Firefox when loading Citrix XenApp
 >     - PR895: IcedTea-Web searches for missing classes on each loadClass or findClass
 > +* Common
 > +  - PR918: java applet windows uses a low resulution black/white icon
 >
 >   New in release 1.2 (2011-XX-XX):
 >   * Security updates:
 > diff --git a/netx/net/sourceforge/jnlp/JNLPSplashScreen.java 
b/netx/net/sourceforge/jnlp/JNLPSplashScreen.java
 > --- a/netx/net/sourceforge/jnlp/JNLPSplashScreen.java
 > +++ b/netx/net/sourceforge/jnlp/JNLPSplashScreen.java
 > @@ -14,6 +14,7 @@
 >
 >   import net.sourceforge.jnlp.cache.ResourceTracker;
 >   import net.sourceforge.jnlp.runtime.JNLPRuntime;
 > +import net.sourceforge.jnlp.util.ImageResources;
 >
 >   public class JNLPSplashScreen extends JDialog {
 >
 > @@ -28,6 +29,8 @@
 >       public JNLPSplashScreen(ResourceTracker resourceTracker,
 >               String applicationTitle, String applicationVendor) {
 >
 > +        setIconImage(new ImageResources().getApplicationImage());
(1)
 > +
 >           // If the JNLP file does not contain any icon images, the splash image
 >           // will consist of the application's title and vendor, as taken from the
 >           // JNLP file.
 > diff --git a/netx/net/sourceforge/jnlp/cache/DefaultDownloadIndicator.java 
b/netx/net/sourceforge/jnlp/cache/DefaultDownloadIndicator.java
 > --- a/netx/net/sourceforge/jnlp/cache/DefaultDownloadIndicator.java
 > +++ b/netx/net/sourceforge/jnlp/cache/DefaultDownloadIndicator.java
 > @@ -28,6 +28,7 @@
 >   import javax.jnlp.*;
 >
 >   import net.sourceforge.jnlp.runtime.*;
 > +import net.sourceforge.jnlp.util.ImageResources;
 >
 >   /**
 >    * Show the progress of downloads.
 > @@ -101,6 +102,7 @@
 >           synchronized (frameMutex) {
 >               if (frame == null) {
 >                   frame = new JFrame(downloading + "...");
 > +                frame.setIconImage(new ImageResources().getApplicationImage());
(2)
 >                   frame.getContentPane().setLayout(new GridBagLayout());
 >               }
 >
 > diff --git a/netx/net/sourceforge/jnlp/controlpanel/AdvancedProxySettingsDialog.java 
b/netx/net/sourceforge/jnlp/controlpanel/AdvancedProxySettingsDialog.java
 > --- a/netx/net/sourceforge/jnlp/controlpanel/AdvancedProxySettingsDialog.java
 > +++ b/netx/net/sourceforge/jnlp/controlpanel/AdvancedProxySettingsDialog.java
 > @@ -31,6 +31,7 @@
 >
 >   import net.sourceforge.jnlp.config.DeploymentConfiguration;
 >   import net.sourceforge.jnlp.runtime.Translator;
 > +import net.sourceforge.jnlp.util.ImageResources;
 >
 >   /**
 >    * This dialog provides a means for user to edit more of the proxy settings.
 > @@ -54,6 +55,8 @@
 >        */
 >       public AdvancedProxySettingsDialog(DeploymentConfiguration config) {
 >           super((Frame) null, dialogTitle, true); // Don't need a parent.
 > +        setIconImage(new ImageResources().getApplicationImage());
(3)
 > +
 >           this.config = config;
 >
 >           /* Prepare for adding components to dialog box */
 > diff --git a/netx/net/sourceforge/jnlp/controlpanel/CacheViewer.java 
b/netx/net/sourceforge/jnlp/controlpanel/CacheViewer.java
 > --- a/netx/net/sourceforge/jnlp/controlpanel/CacheViewer.java
 > +++ b/netx/net/sourceforge/jnlp/controlpanel/CacheViewer.java
 > @@ -30,6 +30,7 @@
 >
 >   import net.sourceforge.jnlp.config.DeploymentConfiguration;
 >   import net.sourceforge.jnlp.runtime.Translator;
 > +import net.sourceforge.jnlp.util.ImageResources;
 >
 >   /**
 >    * This class will provide a visual way of viewing cache.
 > @@ -51,6 +52,7 @@
 >        */
 >       public CacheViewer(DeploymentConfiguration config) {
 >           super((Frame) null, dialogTitle, true); // Don't need a parent.
 > +        setIconImage(new ImageResources().getApplicationImage());
(4)
 >           this.config = config;
 >
 >           /* Prepare for adding components to dialog box */
 > diff --git a/netx/net/sourceforge/jnlp/controlpanel/ControlPanel.java 
b/netx/net/sourceforge/jnlp/controlpanel/ControlPanel.java
 > --- a/netx/net/sourceforge/jnlp/controlpanel/ControlPanel.java
 > +++ b/netx/net/sourceforge/jnlp/controlpanel/ControlPanel.java
 > @@ -55,6 +55,7 @@
 >   import net.sourceforge.jnlp.runtime.Translator;
 >   import net.sourceforge.jnlp.security.KeyStores;
 >   import net.sourceforge.jnlp.security.viewer.CertificatePane;
 > +import net.sourceforge.jnlp.util.ImageResources;
 >
 >   /**
 >    * This is the control panel for Java. It provides a GUI for modifying the
 > @@ -102,6 +103,7 @@
 >       public ControlPanel(DeploymentConfiguration config) {
 >           super();
 >           setTitle(Translator.R("CPHead"));
 > +        setIconImage(new ImageResources().getApplicationImage());
(5)
 >
 >           this.config = config;
 >
 > diff --git a/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java 
b/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java
 > --- a/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java
 > +++ b/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java
 > @@ -94,9 +94,6 @@
 >       /** update policy that controls when to check for updates */
 >       private static UpdatePolicy updatePolicy = UpdatePolicy.ALWAYS;
 >
 > -    /** netx window icon */
 > -    private static Image windowIcon = null;
 > -
 >       /** whether initialized */
 >       private static boolean initialized = false;
 >
 > @@ -188,9 +185,6 @@
 >           if (headless == false)
 >               checkHeadless();
 >
 > -        if (!headless&&  windowIcon == null)
 > -            loadWindowIcon();
 > -
hmhm - it was cached :)
 >           if (!headless&&  indicator == null)
 >               indicator = new DefaultDownloadIndicator();
 >
 > @@ -336,24 +330,6 @@
 >       }
 >
 >       /**
 > -     * Returns the window icon.
 > -     */
 > -    public static Image getWindowIcon() {
 > -        return windowIcon;
 > -    }
 > -
 > -    /**
 > -     * Sets the window icon that is displayed in Java applications
 > -     * and applets instead of the default Java icon.
 > -     *
 > -     * @throws IllegalStateException if caller is not the exit class
 > -     */
 > -    public static void setWindowIcon(Image image) {
 > -        checkExitClass();
 > -        windowIcon = image;
 > -    }
 > -
 > -    /**
 >        * Returns whether the JNLP client will use any AWT/Swing
 >        * components.
 >        */
 > @@ -622,22 +598,6 @@
 >       }
 >
 >       /**
 > -     * Load the window icon.
 > -     */
 > -    private static void loadWindowIcon() {
 > -        if (windowIcon != null)
 > -            return;
 > -
 > -        try {
 > -            windowIcon = new javax.swing.ImageIcon((new sun.misc.Launcher())
 > - 
.getClassLoader().getResource("net/sourceforge/jnlp/resources/netx-icon.png")).getImage();
 > -        } catch (Exception ex) {
 > -            if (JNLPRuntime.isDebug())
 > -                ex.printStackTrace();
 > -        }
 > -    }
 > -
 > -    /**
 >        * @return true if running on Windows
 >        */
 >       public static boolean isWindows() {
 > diff --git a/netx/net/sourceforge/jnlp/runtime/JNLPSecurityManager.java 
b/netx/net/sourceforge/jnlp/runtime/JNLPSecurityManager.java
 > --- a/netx/net/sourceforge/jnlp/runtime/JNLPSecurityManager.java
 > +++ b/netx/net/sourceforge/jnlp/runtime/JNLPSecurityManager.java
 > @@ -350,12 +350,6 @@
 >               app.addWindow(w);
 >           }
 >
 > -        // change coffee cup to netx for default icon
 > -        if (window instanceof Window)
 > -            for (Window w = (Window) window; w != null; w = w.getOwner())
 > -                if (window instanceof Frame)
 > -                    ((Frame) window).setIconImage(JNLPRuntime.getWindowIcon());
 > -
 >           // todo: set awt.appletWarning to custom message
 >           // todo: logo on with glass pane on JFrame/JWindow?
 >
 > diff --git a/netx/net/sourceforge/jnlp/security/SecurityDialog.java 
b/netx/net/sourceforge/jnlp/security/SecurityDialog.java
 > --- a/netx/net/sourceforge/jnlp/security/SecurityDialog.java
 > +++ b/netx/net/sourceforge/jnlp/security/SecurityDialog.java
 > @@ -41,6 +41,7 @@
 >   import net.sourceforge.jnlp.runtime.JNLPRuntime;
 >   import net.sourceforge.jnlp.security.SecurityDialogs.AccessType;
 >   import net.sourceforge.jnlp.security.SecurityDialogs.DialogType;
 > +import net.sourceforge.jnlp.util.ImageResources;
 >
 >   import java.awt.*;
 >
 > @@ -98,6 +99,7 @@
 >       SecurityDialog(DialogType dialogType, AccessType accessType,
 >                   JNLPFile file, CertVerifier JarCertVerifier, X509Certificate cert, Object[] 
extras) {
 >           super();
 > +        setIconImage(new ImageResources().getApplicationImage());
(6)
 >           this.dialogType = dialogType;
 >           this.accessType = accessType;
 >           this.file = file;
 > diff --git a/netx/net/sourceforge/jnlp/security/viewer/CertificateViewer.java 
b/netx/net/sourceforge/jnlp/security/viewer/CertificateViewer.java
 > --- a/netx/net/sourceforge/jnlp/security/viewer/CertificateViewer.java
 > +++ b/netx/net/sourceforge/jnlp/security/viewer/CertificateViewer.java
 > @@ -51,6 +51,7 @@
 >   import javax.swing.UIManager;
 >
 >   import net.sourceforge.jnlp.runtime.JNLPRuntime;
 > +import net.sourceforge.jnlp.util.ImageResources;
 >
 >   public class CertificateViewer extends JDialog {
 >
 > @@ -61,6 +62,7 @@
 >
 >       public CertificateViewer() {
 >           super((Frame) null, dialogTitle, true);
 > +        setIconImage(new ImageResources().getApplicationImage());
(7)
 >
 >           Container contentPane = getContentPane();
 >           contentPane.setLayout(new BorderLayout());
 > diff --git a/netx/net/sourceforge/jnlp/util/BasicExceptionDialog.java 
b/netx/net/sourceforge/jnlp/util/BasicExceptionDialog.java
 > --- a/netx/net/sourceforge/jnlp/util/BasicExceptionDialog.java
 > +++ b/netx/net/sourceforge/jnlp/util/BasicExceptionDialog.java
 > @@ -82,6 +82,7 @@
 >
 >           JOptionPane optionPane = new JOptionPane(mainPanel, JOptionPane.ERROR_MESSAGE);
 >           final JDialog errorDialog = optionPane.createDialog(R("Error"));
 > +        errorDialog.setIconImage(new ImageResources().getApplicationImage());
(8)
 >
 >           final JPanel quickInfoPanel = new JPanel();
 >           BoxLayout layout = new BoxLayout(quickInfoPanel, BoxLayout.Y_AXIS);
 > diff --git a/netx/net/sourceforge/jnlp/util/ImageResources.java 
b/netx/net/sourceforge/jnlp/util/ImageResources.java
 > new file mode 100644
 > --- /dev/null
 > +++ b/netx/net/sourceforge/jnlp/util/ImageResources.java
 > @@ -0,0 +1,69 @@
 > +/* ImageResources.java
 > +   Copyright (C) 2012 Red Hat, Inc.
 > +
 > +This file is part of IcedTea.
 > +
 > +IcedTea is free software; you can redistribute it and/or modify
 > +it under the terms of the GNU General Public License as published by
 > +the Free Software Foundation; either version 2, or (at your option)
 > +any later version.
 > +
 > +IcedTea is distributed in the hope that it will be useful, but
 > +WITHOUT ANY WARRANTY; without even the implied warranty of
 > +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 > +General Public License for more details.
 > +
 > +You should have received a copy of the GNU General Public License
 > +along with IcedTea; see the file COPYING.  If not, write to the
 > +Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
 > +02110-1301 USA.
 > +
 > +Linking this library statically or dynamically with other modules is
 > +making a combined work based on this library.  Thus, the terms and
 > +conditions of the GNU General Public License cover the whole
 > +combination.
 > +
 > +As a special exception, the copyright holders of this library give you
 > +permission to link this library with independent modules to produce an
 > +executable, regardless of the license terms of these independent
 > +modules, and to copy and distribute the resulting executable under
 > +terms of your choice, provided that you also meet, for each linked
 > +independent module, the terms and conditions of the license of that
 > +module.  An independent module is a module which is not derived from
 > +or based on this library.  If you modify this library, you may extend
 > +this exception to your version of the library, but you are not
 > +obligated to do so.  If you do not wish to do so, delete this
 > +exception statement from your version. */
 > +
 > +package net.sourceforge.jnlp.util;
 > +
 > +import java.awt.Image;
 > +import java.io.IOException;
 > +import java.io.InputStream;
 > +
 > +import javax.imageio.ImageIO;
 > +
 > +public class ImageResources {
As I told, this should be static or provide singleton instance.
Also imageicon, however small should be cahced.
 > +
I would suggest IconLoadingException as it have no other usages rigth n ow.

 > +    public static class ImageLoadingException extends RuntimeException {
 > +        public ImageLoadingException(Throwable cause) {
 > +            super(cause);
 > +        }
 > +    }
Why this? isnt Runtime exception enough?  If you insists Why not public class in separate file?
 > +
 > +    private static final String APPLICATION_ICON_PATH = 
"net/sourceforge/jnlp/resources/netx-icon.png";

I see an issue in following code. When
this.getClass().getClassLoader() is got, and it is not systemClassLoader then it search for resource 
by relative path  - so your path will not be valid.
I'm for usage of ClassLoader.getSystemClassLoader() in all ways.
 > +
 > +    public Image getApplicationImage() throws ImageLoadingException {
 > +        ClassLoader cl = this.getClass().getClassLoader();
 > +        if (cl == null) {
 > +            cl = ClassLoader.getSystemClassLoader();
 > +        }
 > +        InputStream in = cl.getResourceAsStream(APPLICATION_ICON_PATH);
 > +        try {
 > +            Image image = ImageIO.read(in);
 > +            return image;
 > +        } catch (IOException ioe) {
 > +            throw new ImageLoadingException(ioe);
It give me sense to have an special exception, but in this case I'm for wrapping all possible 
exceptions. if image is null. I'snt worthy to return eg red square?
Also I think that when this really fails, it should not propagate an exception, (but it should be 
printStackTraced in debug mode of course!).
Because if the icons will be just default, then it is better to have default cofe cup rather then fail.
(Although the possibility of failure is very small, and there is always point of view to die earlier 
then later)
 > +        }
 > +    }
 > +}
 > diff --git a/plugin/icedteanp/java/sun/applet/JavaConsole.java 
b/plugin/icedteanp/java/sun/applet/JavaConsole.java
 > --- a/plugin/icedteanp/java/sun/applet/JavaConsole.java
 > +++ b/plugin/icedteanp/java/sun/applet/JavaConsole.java
 > @@ -65,6 +65,7 @@
 >
 >   import net.sourceforge.jnlp.config.DeploymentConfiguration;
 >   import net.sourceforge.jnlp.runtime.JNLPRuntime;
 > +import net.sourceforge.jnlp.util.ImageResources;
 >
 >   /**
 >    * A simple Java console for IcedTeaPlugin
 > @@ -92,6 +93,7 @@
 >           final String logDir = 
JNLPRuntime.getConfiguration().getProperty(DeploymentConfiguration.KEY_USER_LOG_DIR);
 >
 >           consoleWindow = new JFrame("Java Console");
 > +        consoleWindow.setIconImage(new ImageResources().getApplicationImage());
(9)
 >
 >           JPanel contentPanel = new JPanel();
 >           contentPanel.setLayout(new GridBagLayout());
 > diff --git a/tests/netx/unit/net/sourceforge/jnlp/util/ImageResourcesTest.java 
b/tests/netx/unit/net/sourceforge/jnlp/util/ImageResourcesTest.java
 > new file mode 100644
 > --- /dev/null
 > +++ b/tests/netx/unit/net/sourceforge/jnlp/util/ImageResourcesTest.java
 > @@ -0,0 +1,54 @@
 > +/* ImageResourcesTest.java
 > +   Copyright (C) 2012 Red Hat, Inc.
 > +
 > +This file is part of IcedTea.
 > +
 > +IcedTea is free software; you can redistribute it and/or modify
 > +it under the terms of the GNU General Public License as published by
 > +the Free Software Foundation; either version 2, or (at your option)
 > +any later version.
 > +
 > +IcedTea is distributed in the hope that it will be useful, but
 > +WITHOUT ANY WARRANTY; without even the implied warranty of
 > +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 > +General Public License for more details.
 > +
 > +You should have received a copy of the GNU General Public License
 > +along with IcedTea; see the file COPYING.  If not, write to the
 > +Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
 > +02110-1301 USA.
 > +
 > +Linking this library statically or dynamically with other modules is
 > +making a combined work based on this library.  Thus, the terms and
 > +conditions of the GNU General Public License cover the whole
 > +combination.
 > +
 > +As a special exception, the copyright holders of this library give you
 > +permission to link this library with independent modules to produce an
 > +executable, regardless of the license terms of these independent
 > +modules, and to copy and distribute the resulting executable under
 > +terms of your choice, provided that you also meet, for each linked
 > +independent module, the terms and conditions of the license of that
 > +module.  An independent module is a module which is not derived from
 > +or based on this library.  If you modify this library, you may extend
 > +this exception to your version of the library, but you are not
 > +obligated to do so.  If you do not wish to do so, delete this
 > +exception statement from your version. */
 > +
 > +package net.sourceforge.jnlp.util;
 > +
 > +import static org.junit.Assert.assertNotNull;
 > +
 > +import java.awt.Image;
 > +
 > +import org.junit.Test;
 > +
 > +public class ImageResourcesTest {
 > +
 > +    @Test
 > +    public void testApplicationIcon() {
 > +        ImageResources imageResources = new ImageResources();
 > +        Image icon = imageResources.getApplicationImage();
 > +        assertNotNull(icon);
 > +    }
 > +}
:)) And who will test if they have really setted to windows? O:)
 >

This is simple and straightforward  patch doing (except possible classloader and path issue) its job 
well.  Feel free to smash  all my hints  (especially "refactoring ones" and  "annoying ones" as you 
wish.

Thanx for nice fix and one of the best tests I have ever seen  :)

Best regards
  J.



From jgh at FreeBSD.org  Wed Apr 18 09:52:42 2012
From: jgh at FreeBSD.org (Jason Helfman)
Date: Wed, 18 Apr 2012 09:52:42 -0700
Subject: porting icedtea6 to FreeBSD
In-Reply-To: <20120418162136.GA96044@dormouse.experts-exchange.com>
References: <20120417193540.GA15370@dormouse.experts-exchange.com>
	<1a99cebe-96a1-4b45-803c-990ad0a81e36@zmail17.collab.prod.int.phx2.redhat.com>
	<20120418162136.GA96044@dormouse.experts-exchange.com>
Message-ID: <20120418165242.GB96044@dormouse.experts-exchange.com>

On Wed, Apr 18, 2012 at 09:21:36AM -0700, Jason Helfman thus spake:
>On Wed, Apr 18, 2012 at 09:23:43AM -0400, Andrew Hughes thus spake:
>>----- Original Message -----
>>> On Tue, Apr 17, 2012 at 08:08:43AM -0700, Jason Helfman thus spake:
>>> >On Tue, Apr 17, 2012 at 7:56 AM, Andrew Hughes <ahughes at redhat.com>
>>> >wrote:
>>> >
>>> >> ----- Original Message -----
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Tue, Apr 17, 2012 at 4:51 AM, Andrew Hughes <
>>> >> > ahughes at redhat.com >
>>> >> > wrote:
>>> >> >
>>> >> >
>>> >> >
>>> >> > ----- Original Message -----
>>> >> > > On Mon, Apr 16, 2012 at 09:59:00AM -0400, Andrew Hughes thus
>>> >> > > spake:
>>> >> > > >> Any thoughts on any of this?
>>> >> > > >> Thanks, again.
>>> >> > > >>
>>> >> > > >> -jgh
>>> >> > > >
>>> >> > > >What are you doing here?
>>> >> > > >
>>> >> > > >/usr/bin/sed -i.bak -e 's|--dry-run||g'
>>> >> > >
>>> >> >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.am
>>> >> > >
>>> >> >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.in
>>> >> > > >/usr/bin/sed -i.bak -e 's|--check|-q|g'
>>> >> > >
>>> >> >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.am
>>> >> > >
>>> >> >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.in
>>> >> > > >
>>> >> > > >If you're removing --dry-run, you're going to be applying the
>>> >> > > >patch
>>> >> > > >twice, which is why it's failing.
>>> >> > > >--
>>> >> > > >Andrew :)
>>> >> > >
>>> >> > > I've modified this to test the patch which in FreeBSD is the
>>> >> > > "-C"
>>> >> > > switch,
>>> >> > > and the "-q" is for SHASUM's to only output the hash.
>>> >> > >
>>> >> > > I was able to get much further in the build! Any thoughts on
>>> >> > > why
>>> >> > > this
>>> >> > > patch
>>> >> > > was seen as already applied?
>>> >> > >
>>> >> >
>>> >> > Because the build tests the patch, then applies it if that
>>> >> > passes. If
>>> >> > you
>>> >> > removed --dry-run from the first invocation and didn't replace
>>> >> > it
>>> >> > with -C,
>>> >> > you'd be applying the patch twice instead.
>>> >> >
>>> >> >
>>> >> >
>>> >> > That is what I have done, though. --dry-run is being replaced
>>> >> > with -C
>>> >> > in the build.
>>> >> > Is something else showing up?
>>> >> >
>>> >> > -jgh
>>> >> >
>>> >> >
>>> >>
>>> >> And it's still failing in the same way?  I thought you said you'd
>>> >> got much
>>> >> further... :-S
>>> >> --
>>> >> Andrew :)
>>> >>
>>> >
>>> >Yes, it is failing in the same way but much further into the build.
>>> >Initially, it would fail at the first/second patch.
>>> >I attached the latest buildlog to my email last night. It should
>>> >show the
>>> >issue, and with what patch the problem
>>> >was with.
>>> >
>>> >-jgh
>>>
>>> I believe I found part of the issue. In the patchset, the file
>>> openjdk/7034464-hugepage.patch has a number of repatched instances
>>> within
>>> os_linux.cpp, which is more than likely the cause of this issue. It
>>> is being
>>> patched twice.
>>>
>>> Starting at line 40, and another starting at line 209.
>>>
>>> For instance, both are adding this information to the same file:
>>>
>>> 47 +// Define MAP_HUGETLB here so we can build HotSpot on old
>>> systems.
>>> 48 +#ifndef MAP_HUGETLB
>>> 49 +#define MAP_HUGETLB 0x40000
>>> 50 +#endif
>>>
>>> 227 +// Define MAP_HUGETLB here so we can build HotSpot on old
>>> systems.
>>> 228 +#ifndef MAP_HUGETLB
>>> 229 +#define MAP_HUGETLB 0x40000
>>> 230 +#endif
>>>
>>> -jgh
>>>
>>> --
>>> Jason Helfman         | FreeBSD Committer
>>> jgh at FreeBSD.org       | http://people.freebsd.org/~jgh
>>>
>>
>>Ah right, now that's more helpful :-)
>>
>>It looks like the patch is a bit messed up, and BSD's patch program
>>is just not as tolerant as the GNU one.  My log shows this:
>>
>>Checking patches/openjdk/7034464-hugepage.patch
>>Applying patches/openjdk/7034464-hugepage.patch
>>patching file openjdk/hotspot/src/os/linux/vm/globals_linux.hpp
>>patching file openjdk/hotspot/src/os/linux/vm/os_linux.cpp
>>patching file openjdk/hotspot/src/os/linux/vm/os_linux.cpp.orig
>>patching file openjdk/hotspot/src/os/linux/vm/os_linux.hpp
>>Checking patches/openjdk/7037939-hugepage.patch
>>Applying patches/openjdk/7037939-hugepage.patch
>>patching file openjdk/hotspot/src/os/linux/vm/os_linux.cpp
>>Hunk #1 succeeded at 4148 (offset -22 lines).
>>patching file openjdk/hotspot/src/os/solaris/vm/os_solaris.cpp
>>Hunk #2 succeeded at 5041 (offset -2 lines).
>>Checking patches/openjdk/7043564-hugepage.patch
>>Applying patches/openjdk/7043564-hugepage.patch
>>patching file openjdk/hotspot/src/os/linux/vm/os_linux.cpp
>>Hunk #1 succeeded at 5084 (offset 2234 lines).
>>
>>I'll look at fixing this up in HEAD, but for BSD you can just disabled these
>>three by deleting the references from Makefile.am.
>
>Great, thanks. I don't see what to delete though. Would you mind sending a
>diff?
>

I've got it. I ended up dropping one more patch file, and now I am getting
this error:

patches/openjdk/7103610-_NET_WM_PID_and_WM_CLIENT_MACHINE_are_not_set.patch
patch: **** misordered hunks! output would be garbled
ERROR patch
patches/openjdk/7103610-_NET_WM_PID_and_WM_CLIENT_MACHINE_are_not_set.patch
FAILED!
WARNING make clean-patch before retrying a fix

Is this patch necessary for FreeBSD?

-jgh

--
Jason Helfman         | FreeBSD Committer
jgh at FreeBSD.org       | http://people.freebsd.org/~jgh


From bugzilla-daemon at icedtea.classpath.org  Wed Apr 18 10:35:11 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Wed, 18 Apr 2012 17:35:11 +0000
Subject: [Bug 955] New: regression: SweetHome3D fails to run
Message-ID: <bug-955-30@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=955

             Bug #: 955
           Summary: regression: SweetHome3D fails to run
    Classification: Unclassified
           Product: IcedTea-Web
           Version: hg
          Platform: all
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: NetX (javaws)
        AssignedTo: omajid at redhat.com
        ReportedBy: omajid at redhat.com
                CC: unassigned at icedtea.classpath.org


With the recent <vendor> change, SweetHome3D fails to run:

$ javaws http://www.sweethome3d.com/SweetHome3D.jnlp
netx: Read Error: Could not read or parse the JNLP file. (The vendor section
has not been defined in the JNLP file.)

-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


From ahughes at redhat.com  Wed Apr 18 16:51:17 2012
From: ahughes at redhat.com (Andrew Hughes)
Date: Wed, 18 Apr 2012 19:51:17 -0400 (EDT)
Subject: porting icedtea6 to FreeBSD
In-Reply-To: <20120418165242.GB96044@dormouse.experts-exchange.com>
Message-ID: <bd8779d7-d1eb-4798-b3e5-76947f4b7d03@zmail17.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> On Wed, Apr 18, 2012 at 09:21:36AM -0700, Jason Helfman thus spake:
> >On Wed, Apr 18, 2012 at 09:23:43AM -0400, Andrew Hughes thus spake:
> >>----- Original Message -----
> >>> On Tue, Apr 17, 2012 at 08:08:43AM -0700, Jason Helfman thus
> >>> spake:
> >>> >On Tue, Apr 17, 2012 at 7:56 AM, Andrew Hughes
> >>> ><ahughes at redhat.com>
> >>> >wrote:
> >>> >
> >>> >> ----- Original Message -----
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> > On Tue, Apr 17, 2012 at 4:51 AM, Andrew Hughes <
> >>> >> > ahughes at redhat.com >
> >>> >> > wrote:
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> > ----- Original Message -----
> >>> >> > > On Mon, Apr 16, 2012 at 09:59:00AM -0400, Andrew Hughes
> >>> >> > > thus
> >>> >> > > spake:
> >>> >> > > >> Any thoughts on any of this?
> >>> >> > > >> Thanks, again.
> >>> >> > > >>
> >>> >> > > >> -jgh
> >>> >> > > >
> >>> >> > > >What are you doing here?
> >>> >> > > >
> >>> >> > > >/usr/bin/sed -i.bak -e 's|--dry-run||g'
> >>> >> > >
> >>> >> >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.am
> >>> >> > >
> >>> >> >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.in
> >>> >> > > >/usr/bin/sed -i.bak -e 's|--check|-q|g'
> >>> >> > >
> >>> >> >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.am
> >>> >> > >
> >>> >> >/usr/local/workspace/redports/java/icedtea6/work/icedtea6-1.11.1/Makefile.in
> >>> >> > > >
> >>> >> > > >If you're removing --dry-run, you're going to be applying
> >>> >> > > >the
> >>> >> > > >patch
> >>> >> > > >twice, which is why it's failing.
> >>> >> > > >--
> >>> >> > > >Andrew :)
> >>> >> > >
> >>> >> > > I've modified this to test the patch which in FreeBSD is
> >>> >> > > the
> >>> >> > > "-C"
> >>> >> > > switch,
> >>> >> > > and the "-q" is for SHASUM's to only output the hash.
> >>> >> > >
> >>> >> > > I was able to get much further in the build! Any thoughts
> >>> >> > > on
> >>> >> > > why
> >>> >> > > this
> >>> >> > > patch
> >>> >> > > was seen as already applied?
> >>> >> > >
> >>> >> >
> >>> >> > Because the build tests the patch, then applies it if that
> >>> >> > passes. If
> >>> >> > you
> >>> >> > removed --dry-run from the first invocation and didn't
> >>> >> > replace
> >>> >> > it
> >>> >> > with -C,
> >>> >> > you'd be applying the patch twice instead.
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> > That is what I have done, though. --dry-run is being
> >>> >> > replaced
> >>> >> > with -C
> >>> >> > in the build.
> >>> >> > Is something else showing up?
> >>> >> >
> >>> >> > -jgh
> >>> >> >
> >>> >> >
> >>> >>
> >>> >> And it's still failing in the same way?  I thought you said
> >>> >> you'd
> >>> >> got much
> >>> >> further... :-S
> >>> >> --
> >>> >> Andrew :)
> >>> >>
> >>> >
> >>> >Yes, it is failing in the same way but much further into the
> >>> >build.
> >>> >Initially, it would fail at the first/second patch.
> >>> >I attached the latest buildlog to my email last night. It should
> >>> >show the
> >>> >issue, and with what patch the problem
> >>> >was with.
> >>> >
> >>> >-jgh
> >>>
> >>> I believe I found part of the issue. In the patchset, the file
> >>> openjdk/7034464-hugepage.patch has a number of repatched
> >>> instances
> >>> within
> >>> os_linux.cpp, which is more than likely the cause of this issue.
> >>> It
> >>> is being
> >>> patched twice.
> >>>
> >>> Starting at line 40, and another starting at line 209.
> >>>
> >>> For instance, both are adding this information to the same file:
> >>>
> >>> 47 +// Define MAP_HUGETLB here so we can build HotSpot on old
> >>> systems.
> >>> 48 +#ifndef MAP_HUGETLB
> >>> 49 +#define MAP_HUGETLB 0x40000
> >>> 50 +#endif
> >>>
> >>> 227 +// Define MAP_HUGETLB here so we can build HotSpot on old
> >>> systems.
> >>> 228 +#ifndef MAP_HUGETLB
> >>> 229 +#define MAP_HUGETLB 0x40000
> >>> 230 +#endif
> >>>
> >>> -jgh
> >>>
> >>> --
> >>> Jason Helfman         | FreeBSD Committer
> >>> jgh at FreeBSD.org       | http://people.freebsd.org/~jgh
> >>>
> >>
> >>Ah right, now that's more helpful :-)
> >>
> >>It looks like the patch is a bit messed up, and BSD's patch program
> >>is just not as tolerant as the GNU one.  My log shows this:
> >>
> >>Checking patches/openjdk/7034464-hugepage.patch
> >>Applying patches/openjdk/7034464-hugepage.patch
> >>patching file openjdk/hotspot/src/os/linux/vm/globals_linux.hpp
> >>patching file openjdk/hotspot/src/os/linux/vm/os_linux.cpp
> >>patching file openjdk/hotspot/src/os/linux/vm/os_linux.cpp.orig
> >>patching file openjdk/hotspot/src/os/linux/vm/os_linux.hpp
> >>Checking patches/openjdk/7037939-hugepage.patch
> >>Applying patches/openjdk/7037939-hugepage.patch
> >>patching file openjdk/hotspot/src/os/linux/vm/os_linux.cpp
> >>Hunk #1 succeeded at 4148 (offset -22 lines).
> >>patching file openjdk/hotspot/src/os/solaris/vm/os_solaris.cpp
> >>Hunk #2 succeeded at 5041 (offset -2 lines).
> >>Checking patches/openjdk/7043564-hugepage.patch
> >>Applying patches/openjdk/7043564-hugepage.patch
> >>patching file openjdk/hotspot/src/os/linux/vm/os_linux.cpp
> >>Hunk #1 succeeded at 5084 (offset 2234 lines).
> >>
> >>I'll look at fixing this up in HEAD, but for BSD you can just
> >>disabled these
> >>three by deleting the references from Makefile.am.
> >
> >Great, thanks. I don't see what to delete though. Would you mind
> >sending a
> >diff?
> >

Sorry only just saw your reply.  Glad you sorted it.

> 
> I've got it. I ended up dropping one more patch file, and now I am
> getting
> this error:
> 
> patches/openjdk/7103610-_NET_WM_PID_and_WM_CLIENT_MACHINE_are_not_set.patch
> patch: **** misordered hunks! output would be garbled
> ERROR patch
> patches/openjdk/7103610-_NET_WM_PID_and_WM_CLIENT_MACHINE_are_not_set.patch
> FAILED!
> WARNING make clean-patch before retrying a fix
> 
> Is this patch necessary for FreeBSD?
> 

It's to make the system tray work correctly with GNOME Shell, so if you're not
using that, then no you don't need it.

I'm curious as to why it failed though...

> -jgh
> 
> --
> Jason Helfman         | FreeBSD Committer
> jgh at FreeBSD.org       | http://people.freebsd.org/~jgh
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From omajid at redhat.com  Wed Apr 18 20:22:37 2012
From: omajid at redhat.com (Omair Majid)
Date: Wed, 18 Apr 2012 23:22:37 -0400
Subject: [icedtea-web] RFC: PR918: java applet windows uses a low
	resulution black/white icon
In-Reply-To: <4F8EEC84.80900@redhat.com>
References: <4F8ED642.30808@redhat.com> <4F8EE1E8.5070504@redhat.com>
	<4F8EE3F9.8030909@redhat.com> <4F8EEC84.80900@redhat.com>
Message-ID: <4F8F84FD.8090908@redhat.com>

On 04/18/2012 12:32 PM, Jiri Vanek wrote:
> On 04/18/2012 05:55 PM, Omair Majid wrote:
>> On 04/18/2012 11:46 AM, Jiri Vanek wrote:
>> 
>> Yes, I can certainly modify ImageResources to take care of more 
>> sizes.
> 
> Then there rises question when to use which :)

Eh? We can just set them all (using setIconImages) and let the window
manager pick whatever it wants! Or do you mean at places other than the
window icon?

> Btw - why have you decided to discard netx icon as default one and 
> use java's one as default for "users windows"?

It seems much better to me to let them use the java/duke icon. The
programs are using the java api and they are running in java. Not sure
that IcedTea-Web should take claim of that and use an icedtea-web icon.
Also, it should ensure more consistency between running a simple program
using command line java and javaws.

I would also claim that this is what the proprietary plugin does, but
then again, they use the same icon as java.

> In case icons will be little bit nicer, then it sounds to me like 
> good idea to have this icons everywhere. Can we determine if user
> ave specified his own? I' afraid we can not :-(

That's what the older code did (or perhaps it tried to do - I am not
sure if it worked in all cases). It changed the icon for all new
windows. The user could set one after the frame window was created.

> Just what I have seen for now:
> 
> You are using on everywhere new Imageresource().getApplicationImage()
> It is not nice.
> 
> It should be static or singleton. My vote is for singleton. Both will
> allow caching, and singleton is "more object like".
> 
> the choice between ImageResources.getInstance().getApplicationImage()
> and ImageResources.getApplicationImage() is up to you but I do not
> like creating new ImageResources() with new icon every time.

Good point. I have changed it to a singleton now.

> Also considering on how much places you have to setIconImage(new 
> ImageResources().getApplicationImage()); (or similar) I'm thinking 
> about pack it somewhere. But I'm not sure how and where. eg new 
> ImageResources().iconizeMainWindows()? or etleast eg new 
> ImageResources().iconizeWindows(Window w)? (but only the first one 
> looks like have sense if possible) And also such a "magical method" 
> can be misleading for future developers.

I am not a huge fan of this idea. I don't like the idea of
ImageReources.iconizeMainWindows(), which would find/modifyy all (or
even any) window. It's not the right place for that. And I am not sure
how much code I will save by writing
ImageResources().iconizeWindows(Window w).

> hmhm - it was cached :)

Doh! I have fixed the new version to do that too.

>> +public class ImageResources {
> As I told, this should be static or provide singleton instance. Also 
> imageicon, however small should be cahced.

Done now.

> I would suggest IconLoadingException as it have no other usages
> rigth now.
> 

I am not entirely clear what you are suggesting here. Are you suggesting
an alternate name for the class? I went with ImageLoadingException as
the main class is *Image*Resources :)

>> +    public static class ImageLoadingException

> Why this? isnt Runtime exception enough?  If you insists Why not 
> public class in separate file?

I wanted something more specific to this class. Do you see any issues
with subclassing RuntimeException here? I didn't think this was general
enough for other classes to use yet, so I didn't put it in a separate file.

Anyway, I have removed this class now (see below), so the discussion is
moot :)

>> + +    private static final String APPLICATION_ICON_PATH =
> "net/sourceforge/jnlp/resources/netx-icon.png";
> 
> I see an issue in following code. When 
> this.getClass().getClassLoader() is got, and it is not 
> systemClassLoader then it search for resource by relative path  - so 
> your path will not be valid. I'm for usage of 
> ClassLoader.getSystemClassLoader() in all ways.

Actually I did this intentionally :)

I want to use the classloader (whatever it is) to find the image file.
It may be that the class loader uses a relative path to resolve it. Or
it may be that the class loader finds this file in one of the jars in
the class path. Either way, I want to be able to run this without
assuming our class is loaded by the system classloader. This allows this
test to be run using an IDE too. It will also allow icedtea-web to work
when netx.jar is not in the boot classpath. This is basically the
pattern that is used throughout netx; there are other examples in netx
code too (the plugin does things differently).

> It give me sense to have an special exception, but in this case I'm 
> for wrapping all possible exceptions. if image is null. I'snt worthy 
> to return eg red square? Also I think that when this really fails,
> it should not propagate an exception, (but it should be
> printStackTraced in debug mode of course!). Because if the icons will
> be just default, then it is better to have default cofe cup rather
> then fail.

Hm.. you have a valid point. While it's good for developers to see a
problem early (and missing icons is almost certainly a bug caused by an
icedtea-web developer), you are right that the program shouldn't fail. I
have changed it to return a null Image. null Images are handled properly
(read: ignored) by java so things continue to work if the image is missing.

> (Although the possibility of failure is very small, and there is 
> always point of view to die earlier then later)

Yeah, I was going for die-early. But that's what the unit test is for :)

> :)) And who will test if they have really setted to windows? O:)

I am not sure how to do that. I feel we need more points in netx where
we can inject objects to write unit tests without going crazy.

> Thanx for nice fix and one of the best tests I have ever seen  :)

I really appreciate the review!

How does the attached (updated) patch look?

Thanks,
Omair
-------------- next part --------------
A non-text attachment was scrubbed...
Name: let-programs-have-default-icons-02.patch
Type: text/x-patch
Size: 17990 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120418/9230209c/let-programs-have-default-icons-02.patch 

From bugzilla-daemon at icedtea.classpath.org  Wed Apr 18 22:58:28 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Thu, 19 Apr 2012 05:58:28 +0000
Subject: [Bug 955] regression: SweetHome3D fails to run
In-Reply-To: <bug-955-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-955-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-955-30-8Qht3JAx1s@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=955

JiriVanek <jvanek at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jvanek at redhat.com
         AssignedTo|omajid at redhat.com           |ddadacha at redhat.com

--- Comment #1 from JiriVanek <jvanek at redhat.com> 2012-04-19 05:58:28 UTC ---
title and version have been done obligatory, however, its localized versions
are not handled properly. The specification is not clean whether to reuse
default one or to fail. But it sounds logical to reuse. Reassigning to Danesh
as the author of original chnageset.
Thanx for bringing the issue, reproducer on the way, and I confess, I forgot to
handle this in splash to.

-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


From jvanek at redhat.com  Thu Apr 19 03:08:10 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Thu, 19 Apr 2012 12:08:10 +0200
Subject: [icedtea-web] RFC: PR918: java applet windows uses a low
	resulution black/white icon
In-Reply-To: <4F8F84FD.8090908@redhat.com>
References: <4F8ED642.30808@redhat.com> <4F8EE1E8.5070504@redhat.com>
	<4F8EE3F9.8030909@redhat.com> <4F8EEC84.80900@redhat.com>
	<4F8F84FD.8090908@redhat.com>
Message-ID: <4F8FE40A.1020801@redhat.com>

On 04/19/2012 05:22 AM, Omair Majid wrote:
> On 04/18/2012 12:32 PM, Jiri Vanek wrote:
>> On 04/18/2012 05:55 PM, Omair Majid wrote:
>>> On 04/18/2012 11:46 AM, Jiri Vanek wrote:
>>>
>>> Yes, I can certainly modify ImageResources to take care of more
>>> sizes.
>>
>> Then there rises question when to use which :)
>
> Eh? We can just set them all (using setIconImages) and let the window
> manager pick whatever it wants! Or do you mean at places other than the
> window icon?
Yes this will probably make the best deal. And is it one more reason to hide the setting of icons 
(as already discussed lower). Or to use setIconImages already now and so prevent future refactoring.
>
>> Btw - why have you decided to discard netx icon as default one and
>> use java's one as default for "users windows"?
>
> It seems much better to me to let them use the java/duke icon. The
> programs are using the java api and they are running in java. Not sure
> that IcedTea-Web should take claim of that and use an icedtea-web icon.
> Also, it should ensure more consistency between running a simple program
> using command line java and javaws.
>
> I would also claim that this is what the proprietary plugin does, but
> then again, they use the same icon as java.

(More then) fair enough.

>
>> In case icons will be little bit nicer, then it sounds to me like
>> good idea to have this icons everywhere. Can we determine if user
>> ave specified his own? I' afraid we can not :-(
>
> That's what the older code did (or perhaps it tried to do - I am not
looks more like it just tried.
> sure if it worked in all cases). It changed the icon for all new
> windows. The user could set one after the frame window was created.
>
>> Just what I have seen for now:
>>
>> You are using on everywhere new Imageresource().getApplicationImage()
>> It is not nice.
>>
>> It should be static or singleton. My vote is for singleton. Both will
>> allow caching, and singleton is "more object like".
>>
>> the choice between ImageResources.getInstance().getApplicationImage()
>> and ImageResources.getApplicationImage() is up to you but I do not
>> like creating new ImageResources() with new icon every time.
>
> Good point. I have changed it to a singleton now.
Thank you:)
>
>> Also considering on how much places you have to setIconImage(new
>> ImageResources().getApplicationImage()); (or similar) I'm thinking
>> about pack it somewhere. But I'm not sure how and where. eg new
>> ImageResources().iconizeMainWindows()? or etleast eg new
>> ImageResources().iconizeWindows(Window w)? (but only the first one
>> looks like have sense if possible) And also such a "magical method"
>> can be misleading for future developers.
>
> I am not a huge fan of this idea. I don't like the idea of
> ImageReources.iconizeMainWindows(), which would find/modifyy all (or
> even any) window. It's not the right place for that. And I am not sure
> how much code I will save by writing
ok.
> ImageResources().iconizeWindows(Window w).
hmhmh. Cannot imagine more refactoring then setIconImage/setIconImages right now (Oh how I miss my 
childhood fantasy :) ) So if we will use setIconImages now, I'm ok.
>
..snipp...
>
>>> + +    private static final String APPLICATION_ICON_PATH =
>> "net/sourceforge/jnlp/resources/netx-icon.png";
>>
>> I see an issue in following code. When
>> this.getClass().getClassLoader() is got, and it is not
>> systemClassLoader then it search for resource by relative path  - so
>> your path will not be valid. I'm for usage of
>> ClassLoader.getSystemClassLoader() in all ways.
>
> Actually I did this intentionally :)
>
> I want to use the classloader (whatever it is) to find the image file.
> It may be that the class loader uses a relative path to resolve it. Or
> it may be that the class loader finds this file in one of the jars in
> the class path. Either way, I want to be able to run this without
> assuming our class is loaded by the system classloader. This allows this
> test to be run using an IDE too. It will also allow icedtea-web to work
> when netx.jar is not in the boot classpath. This is basically the
> pattern that is used throughout netx; there are other examples in netx
> code too (the plugin does things differently).
Well if this is pattern then I'm ok. However I still consider it wrong and cannot imagine how this 
can be better then simple ClassLoader.getSystemClassLoader() (which is working in ide, on 
boot/classpath...)
>
>> It give me sense to have an special exception, but in this case I'm
>> for wrapping all possible exceptions. if image is null. I'snt worthy
>> to return eg red square? Also I think that when this really fails,
>> it should not propagate an exception, (but it should be
>> printStackTraced in debug mode of course!). Because if the icons will
>> be just default, then it is better to have default cofe cup rather
>> then fail.
>
> Hm.. you have a valid point. While it's good for developers to see a
> problem early (and missing icons is almost certainly a bug caused by an
> icedtea-web developer), you are right that the program shouldn't fail. I
> have changed it to return a null Image. null Images are handled properly
> (read: ignored) by java so things continue to work if the image is missing.
>
Excelent!
>> (Although the possibility of failure is very small, and there is
>> always point of view to die earlier then later)
>
> Yeah, I was going for die-early. But that's what the unit test is for :)
>
>> :)) And who will test if they have really setted to windows? O:)
>
> I am not sure how to do that. I feel we need more points in netx where
> we can inject objects to write unit tests without going crazy.
>
ok.
>> Thanx for nice fix and one of the best tests I have ever seen  :)
>
> I really appreciate the review!
>
> How does the attached (updated) patch look?
Much better:) Few comments inline but you can go ahead without accepting them.
>

 > let-programs-have-default-icons-02.patch
 >
 >
 > diff --git a/ChangeLog b/ChangeLog
 > --- a/ChangeLog
 > +++ b/ChangeLog
 > @@ -1,3 +1,33 @@
 > +2012-04-18  Omair Majid<omajid at redhat.com>
 > +
 > +	PR918: java applet windows uses a low resulution black/white icon
 > +	* NEWS: Update with fix.
 > +	* netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java: Remove windowIcon.
 > +	(initialize): Do not call loadWindowIcon.
 > +	(getWindowIcon): Remove.
 > +	(setWindowIcon): Remove.
 > +	(loadWindowIcon): Remove.
 > +	* netx/net/sourceforge/jnlp/runtime/JNLPSecurityManager.java
 > +	(checkTopLevelWindow): Do not set the icon for all top level windows. Use
 > +	the default java icon instead.
 > +	* netx/net/sourceforge/jnlp/util/ImageResources.java: New file. Provides
 > +	access to icons.
 > +	* netx/net/sourceforge/jnlp/JNLPSplashScreen.java (JNLPSplashScreen),
 > +	* netx/net/sourceforge/jnlp/cache/DefaultDownloadIndicator.java
 > +	(getListener),
 > +	* netx/net/sourceforge/jnlp/controlpanel/AdvancedProxySettingsDialog.java
 > +	(AdvancedProxySettingsDialog),
 > +	* netx/net/sourceforge/jnlp/controlpanel/CacheViewer.java (CacheViewer),
 > +	* netx/net/sourceforge/jnlp/controlpanel/ControlPanel.java (ControlPanel),
 > +	* netx/net/sourceforge/jnlp/security/SecurityDialog.java (SecurityDialog),
 > +	* netx/net/sourceforge/jnlp/security/viewer/CertificateViewer.java
 > +	(CertificateViewer),
 > +	* netx/net/sourceforge/jnlp/util/BasicExceptionDialog.java (show),
 > +	* plugin/icedteanp/java/sun/applet/JavaConsole.java (initialize):
 > +	Explicitly load icons.
 > +	* tests/netx/unit/net/sourceforge/jnlp/util/ImageResourcesTest.java: Test
 > +	for ImageResources class.
 > +
 >   2012-04-18  Jiri Vanek<jvanek at redhat.com>
 >
 >   	Allowed signed applets in automatic reproducers tests
 > diff --git a/NEWS b/NEWS
 > --- a/NEWS
 > +++ b/NEWS
 > @@ -14,6 +14,8 @@
 >   * Plugin
 >     - PR820: IcedTea-Web 1.1.3 crashing Firefox when loading Citrix XenApp
 >     - PR895: IcedTea-Web searches for missing classes on each loadClass or findClass
 > +* Common
 > +  - PR918: java applet windows uses a low resulution black/white icon
 >
 >   New in release 1.2 (2011-XX-XX):
 >   * Security updates:
 > diff --git a/netx/net/sourceforge/jnlp/JNLPSplashScreen.java 
b/netx/net/sourceforge/jnlp/JNLPSplashScreen.java
 > --- a/netx/net/sourceforge/jnlp/JNLPSplashScreen.java
 > +++ b/netx/net/sourceforge/jnlp/JNLPSplashScreen.java
 > @@ -14,6 +14,7 @@
 >
 >   import net.sourceforge.jnlp.cache.ResourceTracker;
 >   import net.sourceforge.jnlp.runtime.JNLPRuntime;
 > +import net.sourceforge.jnlp.util.ImageResources;
 >
 >   public class JNLPSplashScreen extends JDialog {
 >
 > @@ -28,6 +29,8 @@
 >       public JNLPSplashScreen(ResourceTracker resourceTracker,
 >               String applicationTitle, String applicationVendor) {
 >
 > +        setIconImage(ImageResources.INSTANCE.getApplicationImage());

for all those lines I would like to use setIconImages(ImageResources.INSTANCE.getApplicationImages());

 > +

...snip...

 >+ public enum ImageResources {

Wou I have never seen this :)
I'm used for pattern like:
class Class{
private static final Class INSTANCE=new Class();

public static Class getInstance(){retrun INSTANCE;}
}

But I like this enum approach. By my lack of knowledge the advantage(but also disadvantge compared 
with yours)  of above is method returning the singleton. But I really like your approach! Can you 
tell me  (just from curiosity) what you consider as advantages for your enum?

 > +
 > +    INSTANCE;
 > +
 > +    private static final String APPLICATION_ICON_PATH = 
"net/sourceforge/jnlp/resources/netx-icon.png";
 > +
 > +    private final Map<String, Image>  cache = new HashMap<String, Image>();
 > +
 > +    private ImageResources() {}
 > +
 > +    /* this is for testing ONLY */
 > +    void clearCache() {
 > +        cache.clear();
 > +    }
 > +
 > +    /**
 > +     * Returns an appropriate image, or null if there are errors loading the image.
 > +     */
Can we agree on return List<Image> right now returning just one one-member-list?
 > +    public Image getApplicationImage() {
 > +        if (cache.containsKey(APPLICATION_ICON_PATH)) {
 > +            return cache.get(APPLICATION_ICON_PATH);
 > +        }
 > +
 > +        ClassLoader cl = this.getClass().getClassLoader();
 > +        if (cl == null) {
 > +            cl = ClassLoader.getSystemClassLoader();
 > +        }
 > +
 > +        InputStream in = cl.getResourceAsStream(APPLICATION_ICON_PATH);
 > +        try {
 > +            Image image = ImageIO.read(in);
 > +            cache.put(APPLICATION_ICON_PATH, image);
 > +            return image;
 > +        } catch (IOException ioe) {
 > +            ioe.printStackTrace();
 > +            return null;
 > +        }
 > +    }
 > +}
 > diff --git a/plugin/icedteanp/java/sun/applet/JavaConsole.java 
b/plugin/icedteanp/java/sun/applet/JavaConsole.java
 > --- a/plugin/icedteanp/java/sun/applet/JavaConsole.java
 > +++ b/plugin/icedteanp/java/sun/applet/JavaConsole.java
 > @@ -65,6 +65,7 @@
 >
 >   import net.sourceforge.jnlp.config.DeploymentConfiguration;
...snip...

Everything else looks ok.

J.


From fcassia at gmail.com  Thu Apr 19 03:14:17 2012
From: fcassia at gmail.com (Fernando Cassia)
Date: Thu, 19 Apr 2012 07:14:17 -0300
Subject: [icedtea-web] RFC: PR918: java applet windows uses a low
	resulution black/white icon
In-Reply-To: <4F8F84FD.8090908@redhat.com>
References: <4F8ED642.30808@redhat.com> <4F8EE1E8.5070504@redhat.com>
	<4F8EE3F9.8030909@redhat.com> <4F8EEC84.80900@redhat.com>
	<4F8F84FD.8090908@redhat.com>
Message-ID: <CACGw4H4QNyWvzutCq4YBOBoOiwb6D1HG=4VyxVr2=4NJbNdTOA@mail.gmail.com>

On Thu, Apr 19, 2012 at 00:22, Omair Majid <omajid at redhat.com> wrote:
> It seems much better to me to let them use the java/duke icon. The
> programs are using the java api and they are running in java. Not sure
> that IcedTea-Web should take claim of that and use an icedtea-web icon.
> Also, it should ensure more consistency between running a simple program
> using command line java and javaws.

+1 to Omair.

It?s Java. A plug-in to run Java apps. The icon should be Java-related.
Unless Icedtea wants to compete against Java branding and mindshare
and further confuse users (as if there were not enough JVMs).

Just my $0.02
FC

-- 
During times of Universal Deceit, telling the truth becomes a revolutionary act
- George Orwell


From ptisnovs at icedtea.classpath.org  Thu Apr 19 08:37:20 2012
From: ptisnovs at icedtea.classpath.org (ptisnovs at icedtea.classpath.org)
Date: Thu, 19 Apr 2012 15:37:20 +0000
Subject: /hg/gfx-test: * src/org/gfxtest/testsuites/ClippingPathByRectang...
Message-ID: <hg.a630b16209f8.1334849840.-6248649288953172555@icedtea.classpath.org>

changeset a630b16209f8 in /hg/gfx-test
details: http://icedtea.classpath.org/hg/gfx-test?cmd=changeset;node=a630b16209f8
author: Pavel Tisnovsky <ptisnovs at redhat.com>
date: Thu Apr 19 17:39:58 2012 +0200

	* src/org/gfxtest/testsuites/ClippingPathByRectangleShape.java:
	Added new tests to this test suite.


diffstat:

 ChangeLog                                                    |    5 +
 src/org/gfxtest/testsuites/ClippingPathByRectangleShape.java |  462 ++++++++++-
 2 files changed, 465 insertions(+), 2 deletions(-)

diffs (truncated from 505 to 500 lines):

diff -r 7adf78a0fba2 -r a630b16209f8 ChangeLog
--- a/ChangeLog	Wed Apr 18 15:10:50 2012 +0200
+++ b/ChangeLog	Thu Apr 19 17:39:58 2012 +0200
@@ -1,3 +1,8 @@
+2012-04-19  Pavel Tisnovsky  <ptisnovs at redhat.com>
+
+	* src/org/gfxtest/testsuites/ClippingPathByRectangleShape.java:
+	Added new tests to this test suite.
+
 2012-04-18  Pavel Tisnovsky  <ptisnovs at redhat.com>
 
 	* src/org/gfxtest/testsuites/ClippingPathByRectangleArea.java:
diff -r 7adf78a0fba2 -r a630b16209f8 src/org/gfxtest/testsuites/ClippingPathByRectangleShape.java
--- a/src/org/gfxtest/testsuites/ClippingPathByRectangleShape.java	Wed Apr 18 15:10:50 2012 +0200
+++ b/src/org/gfxtest/testsuites/ClippingPathByRectangleShape.java	Thu Apr 19 17:39:58 2012 +0200
@@ -74,6 +74,8 @@
 @Zoom(1)
 public class ClippingPathByRectangleShape extends GfxTest
 {
+    private static final float[] DOTTED_PATTERN = new float[] {1,40};
+
     /**
      * Prepare canvas for the rendering.
      *
@@ -1110,7 +1112,7 @@
 
     /**
      * Check if line path could be clipped by a rectangle shape. Path is rendered
-     * using dotted stroke paint with normal stroke width and using round cap style.
+     * using dotted stroke paint with normal stroke width.
      * 
      * @param image
      *            work image
@@ -1125,7 +1127,7 @@
         // set stroke width
         //CommonRenderingStyles.setStrokeThickWidth(graphics2d, BasicStroke.CAP_ROUND);
         // set dashed pattern
-        CommonRenderingStyles.setDashedStrokePattern(graphics2d, new float[] {1,20});
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
         // set clip region and draw the path
         drawLinePathClippedByRectangleShape(image, graphics2d);
         // test result
@@ -1133,6 +1135,462 @@
     }
 
     /**
+     * Check if quadratic path could be clipped by a rectangle shape. Path is rendered
+     * using dotted stroke paint with normal stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipQuadraticPathByRectangleShapeDottedStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        //CommonRenderingStyles.setStrokeThickWidth(graphics2d, BasicStroke.CAP_ROUND);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawQuadraticPathClippedByRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if cubic path could be clipped by a rectangle shape. Path is rendered
+     * using dotted stroke paint with normal stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipCubicPathByRectangleShapeDottedStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        //CommonRenderingStyles.setStrokeThickWidth(graphics2d, BasicStroke.CAP_ROUND);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawCubicPathClippedByRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if closed path could be clipped by a rectangle shape. Path is rendered
+     * using dotted stroke paint with normal stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipClosedPathByRectangleShapeDottedStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        //CommonRenderingStyles.setStrokeThickWidth(graphics2d, BasicStroke.CAP_ROUND);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawClosedPathClippedByRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if crossed closed path could be clipped by a rectangle shape. Path is rendered
+     * using dotted stroke paint with normal stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipCrossedClosedPathByRectangleShapeDottedStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        //CommonRenderingStyles.setStrokeThickWidth(graphics2d, BasicStroke.CAP_ROUND);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawCrossedClosedPathClippedByRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if line path could be clipped by a rectangle shape. Path is rendered
+     * using dotted stroke paint with zero stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipLinePathByRectangleShapeDottedZeroStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeZeroThick(graphics2d);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawLinePathClippedByRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if quadratic path could be clipped by a rectangle shape. Path is rendered
+     * using dotted stroke paint with zero stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipQuadraticPathByRectangleShapeDottedZeroStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeZeroThick(graphics2d);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawQuadraticPathClippedByRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if cubic path could be clipped by a rectangle shape. Path is rendered
+     * using dotted stroke paint with zero stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipCubicPathByRectangleShapeDottedZeroStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeZeroThick(graphics2d);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawCubicPathClippedByRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if closed path could be clipped by a rectangle shape. Path is rendered
+     * using dotted stroke paint with zero stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipClosedPathByRectangleShapeDottedZeroStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeZeroThick(graphics2d);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawClosedPathClippedByRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if crossed closed path could be clipped by a rectangle shape. Path is rendered
+     * using dotted stroke paint with zero stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipCrossedClosedPathByRectangleShapeDottedZeroStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeZeroThick(graphics2d);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawCrossedClosedPathClippedByRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if line path could be clipped by a rectangle shape. Path is rendered
+     * using dotted stroke paint with thick stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipLinePathByRectangleShapeDottedThickStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeThickWidth(graphics2d, BasicStroke.CAP_ROUND);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawLinePathClippedByRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if quadratic path could be clipped by a rectangle shape. Path is rendered
+     * using dotted stroke paint with thick stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipQuadraticPathByRectangleShapeDottedThickStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeThickWidth(graphics2d, BasicStroke.CAP_ROUND);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawQuadraticPathClippedByRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if cubic path could be clipped by a rectangle shape. Path is rendered
+     * using dotted stroke paint with thick stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipCubicPathByRectangleShapeDottedThickStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeThickWidth(graphics2d, BasicStroke.CAP_ROUND);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawCubicPathClippedByRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if closed path could be clipped by a rectangle shape. Path is rendered
+     * using dotted stroke paint with thick stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipClosedPathByRectangleShapeDottedThickStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeThickWidth(graphics2d, BasicStroke.CAP_ROUND);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawClosedPathClippedByRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if crossed closed path could be clipped by a rectangle shape. Path is rendered
+     * using dotted stroke paint with thick stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipCrossedClosedPathByRectangleShapeDottedThickStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeThickWidth(graphics2d, BasicStroke.CAP_ROUND);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawCrossedClosedPathClippedByRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if line path could be clipped by a rectangle shape. Path is rendered
+     * using dotted stroke paint with extra thick stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipLinePathByRectangleShapeDottedExtraThickStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeExtraThickWidth(graphics2d, BasicStroke.CAP_ROUND);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawLinePathClippedByRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if quadratic path could be clipped by a rectangle shape. Path is rendered
+     * using dotted stroke paint with extra thick stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipQuadraticPathByRectangleShapeDottedExtraThickStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeExtraThickWidth(graphics2d, BasicStroke.CAP_ROUND);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawQuadraticPathClippedByRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if cubic path could be clipped by a rectangle shape. Path is rendered
+     * using dotted stroke paint with extra thick stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipCubicPathByRectangleShapeDottedExtraThickStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeExtraThickWidth(graphics2d, BasicStroke.CAP_ROUND);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawCubicPathClippedByRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if closed path could be clipped by a rectangle shape. Path is rendered
+     * using dotted stroke paint with extra thick stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipClosedPathByRectangleShapeDottedExtraThickStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeExtraThickWidth(graphics2d, BasicStroke.CAP_ROUND);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawClosedPathClippedByRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if crossed closed path could be clipped by a rectangle shape. Path is rendered
+     * using dotted stroke paint with extra thick stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipCrossedClosedPathByRectangleShapeDottedExtraThickStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render clip rectangle
+        CommonClippingOperations.renderClipRectangle(image, graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeExtraThickWidth(graphics2d, BasicStroke.CAP_ROUND);
+        // set dashed pattern
+        CommonRenderingStyles.setDashedStrokePattern(graphics2d, DOTTED_PATTERN);
+        // set clip region and draw the path
+        drawCrossedClosedPathClippedByRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }


From omajid at icedtea.classpath.org  Thu Apr 19 09:37:44 2012
From: omajid at icedtea.classpath.org (omajid at icedtea.classpath.org)
Date: Thu, 19 Apr 2012 16:37:44 +0000
Subject: /hg/icedtea-web: PR918: java applet windows uses a low resulutio...
Message-ID: <hg.f13777a89e0d.1334853464.8643924302249223276@icedtea.classpath.org>

changeset f13777a89e0d in /hg/icedtea-web
details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=f13777a89e0d
author: Omair Majid <omajid at redhat.com>
date: Thu Apr 19 12:36:43 2012 -0400

	PR918: java applet windows uses a low resulution black/white icon

	2012-04-19  Omair Majid  <omajid at redhat.com>

	    * NEWS: Update with fix.
	    * netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java: Remove windowIcon.
	    (initialize): Do not call loadWindowIcon.
	    (getWindowIcon): Remove.
	    (setWindowIcon): Remove.
	    (loadWindowIcon): Remove.
	    * netx/net/sourceforge/jnlp/runtime/JNLPSecurityManager.java
	    (checkTopLevelWindow): Do not set the icon for all top level windows. Use
	    the default java icon instead.
	    * netx/net/sourceforge/jnlp/util/ImageResources.java: New file. Provides
	    access to icons.
	    * netx/net/sourceforge/jnlp/JNLPSplashScreen.java (JNLPSplashScreen),
	    * netx/net/sourceforge/jnlp/cache/DefaultDownloadIndicator.java
	    (getListener),
	    * netx/net/sourceforge/jnlp/controlpanel/AdvancedProxySettingsDialog.java
	    (AdvancedProxySettingsDialog),
	    * netx/net/sourceforge/jnlp/controlpanel/CacheViewer.java (CacheViewer),
	    * netx/net/sourceforge/jnlp/controlpanel/ControlPanel.java (ControlPanel),
	    * netx/net/sourceforge/jnlp/security/SecurityDialog.java (SecurityDialog),
	    * netx/net/sourceforge/jnlp/security/viewer/CertificateViewer.java
	    (CertificateViewer),
	    * netx/net/sourceforge/jnlp/util/BasicExceptionDialog.java (show),
	    * plugin/icedteanp/java/sun/applet/JavaConsole.java (initialize):
	    Explicitly load icons.
	    * tests/netx/unit/net/sourceforge/jnlp/util/ImageResourcesTest.java: Test
	    for ImageResources class.


diffstat:

 ChangeLog                                                               |   30 ++
 NEWS                                                                    |    2 +
 netx/net/sourceforge/jnlp/JNLPSplashScreen.java                         |    3 +
 netx/net/sourceforge/jnlp/cache/DefaultDownloadIndicator.java           |    2 +
 netx/net/sourceforge/jnlp/controlpanel/AdvancedProxySettingsDialog.java |    3 +
 netx/net/sourceforge/jnlp/controlpanel/CacheViewer.java                 |    2 +
 netx/net/sourceforge/jnlp/controlpanel/ControlPanel.java                |    2 +
 netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java                      |   40 ---
 netx/net/sourceforge/jnlp/runtime/JNLPSecurityManager.java              |    6 -
 netx/net/sourceforge/jnlp/security/SecurityDialog.java                  |    2 +
 netx/net/sourceforge/jnlp/security/viewer/CertificateViewer.java        |    2 +
 netx/net/sourceforge/jnlp/util/BasicExceptionDialog.java                |    1 +
 netx/net/sourceforge/jnlp/util/ImageResources.java                      |  101 ++++++++++
 plugin/icedteanp/java/sun/applet/JavaConsole.java                       |    2 +
 tests/netx/unit/net/sourceforge/jnlp/util/ImageResourcesTest.java       |   71 +++++++
 15 files changed, 223 insertions(+), 46 deletions(-)

diffs (481 lines):

diff -r 14dcb4fb43ac -r f13777a89e0d ChangeLog
--- a/ChangeLog	Wed Apr 18 12:28:08 2012 +0200
+++ b/ChangeLog	Thu Apr 19 12:36:43 2012 -0400
@@ -1,3 +1,33 @@
+2012-04-19  Omair Majid  <omajid at redhat.com>
+
+	PR918: java applet windows uses a low resulution black/white icon
+	* NEWS: Update with fix.
+	* netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java: Remove windowIcon.
+	(initialize): Do not call loadWindowIcon.
+	(getWindowIcon): Remove.
+	(setWindowIcon): Remove.
+	(loadWindowIcon): Remove.
+	* netx/net/sourceforge/jnlp/runtime/JNLPSecurityManager.java
+	(checkTopLevelWindow): Do not set the icon for all top level windows. Use
+	the default java icon instead.
+	* netx/net/sourceforge/jnlp/util/ImageResources.java: New file. Provides
+	access to icons.
+	* netx/net/sourceforge/jnlp/JNLPSplashScreen.java (JNLPSplashScreen),
+	* netx/net/sourceforge/jnlp/cache/DefaultDownloadIndicator.java
+	(getListener),
+	* netx/net/sourceforge/jnlp/controlpanel/AdvancedProxySettingsDialog.java
+	(AdvancedProxySettingsDialog),
+	* netx/net/sourceforge/jnlp/controlpanel/CacheViewer.java (CacheViewer),
+	* netx/net/sourceforge/jnlp/controlpanel/ControlPanel.java (ControlPanel),
+	* netx/net/sourceforge/jnlp/security/SecurityDialog.java (SecurityDialog),
+	* netx/net/sourceforge/jnlp/security/viewer/CertificateViewer.java
+	(CertificateViewer),
+	* netx/net/sourceforge/jnlp/util/BasicExceptionDialog.java (show),
+	* plugin/icedteanp/java/sun/applet/JavaConsole.java (initialize):
+	Explicitly load icons.
+	* tests/netx/unit/net/sourceforge/jnlp/util/ImageResourcesTest.java: Test
+	for ImageResources class.
+
 2012-04-18  Jiri Vanek  <jvanek at redhat.com>
 
 	Allowed signed applets in automatic reproducers tests
diff -r 14dcb4fb43ac -r f13777a89e0d NEWS
--- a/NEWS	Wed Apr 18 12:28:08 2012 +0200
+++ b/NEWS	Thu Apr 19 12:36:43 2012 -0400
@@ -14,6 +14,8 @@
 * Plugin
   - PR820: IcedTea-Web 1.1.3 crashing Firefox when loading Citrix XenApp
   - PR895: IcedTea-Web searches for missing classes on each loadClass or findClass
+* Common
+  - PR918: java applet windows uses a low resulution black/white icon
 
 New in release 1.2 (2011-XX-XX):
 * Security updates:
diff -r 14dcb4fb43ac -r f13777a89e0d netx/net/sourceforge/jnlp/JNLPSplashScreen.java
--- a/netx/net/sourceforge/jnlp/JNLPSplashScreen.java	Wed Apr 18 12:28:08 2012 +0200
+++ b/netx/net/sourceforge/jnlp/JNLPSplashScreen.java	Thu Apr 19 12:36:43 2012 -0400
@@ -14,6 +14,7 @@
 
 import net.sourceforge.jnlp.cache.ResourceTracker;
 import net.sourceforge.jnlp.runtime.JNLPRuntime;
+import net.sourceforge.jnlp.util.ImageResources;
 
 public class JNLPSplashScreen extends JDialog {
 
@@ -28,6 +29,8 @@
     public JNLPSplashScreen(ResourceTracker resourceTracker,
             String applicationTitle, String applicationVendor) {
 
+        setIconImages(ImageResources.INSTANCE.getApplicationImages());
+
         // If the JNLP file does not contain any icon images, the splash image
         // will consist of the application's title and vendor, as taken from the
         // JNLP file.
diff -r 14dcb4fb43ac -r f13777a89e0d netx/net/sourceforge/jnlp/cache/DefaultDownloadIndicator.java
--- a/netx/net/sourceforge/jnlp/cache/DefaultDownloadIndicator.java	Wed Apr 18 12:28:08 2012 +0200
+++ b/netx/net/sourceforge/jnlp/cache/DefaultDownloadIndicator.java	Thu Apr 19 12:36:43 2012 -0400
@@ -28,6 +28,7 @@
 import javax.jnlp.*;
 
 import net.sourceforge.jnlp.runtime.*;
+import net.sourceforge.jnlp.util.ImageResources;
 
 /**
  * Show the progress of downloads.
@@ -101,6 +102,7 @@
         synchronized (frameMutex) {
             if (frame == null) {
                 frame = new JFrame(downloading + "...");
+                frame.setIconImages(ImageResources.INSTANCE.getApplicationImages());
                 frame.getContentPane().setLayout(new GridBagLayout());
             }
 
diff -r 14dcb4fb43ac -r f13777a89e0d netx/net/sourceforge/jnlp/controlpanel/AdvancedProxySettingsDialog.java
--- a/netx/net/sourceforge/jnlp/controlpanel/AdvancedProxySettingsDialog.java	Wed Apr 18 12:28:08 2012 +0200
+++ b/netx/net/sourceforge/jnlp/controlpanel/AdvancedProxySettingsDialog.java	Thu Apr 19 12:36:43 2012 -0400
@@ -31,6 +31,7 @@
 
 import net.sourceforge.jnlp.config.DeploymentConfiguration;
 import net.sourceforge.jnlp.runtime.Translator;
+import net.sourceforge.jnlp.util.ImageResources;
 
 /**
  * This dialog provides a means for user to edit more of the proxy settings.
@@ -54,6 +55,8 @@
      */
     public AdvancedProxySettingsDialog(DeploymentConfiguration config) {
         super((Frame) null, dialogTitle, true); // Don't need a parent.
+        setIconImages(ImageResources.INSTANCE.getApplicationImages());
+
         this.config = config;
 
         /* Prepare for adding components to dialog box */
diff -r 14dcb4fb43ac -r f13777a89e0d netx/net/sourceforge/jnlp/controlpanel/CacheViewer.java
--- a/netx/net/sourceforge/jnlp/controlpanel/CacheViewer.java	Wed Apr 18 12:28:08 2012 +0200
+++ b/netx/net/sourceforge/jnlp/controlpanel/CacheViewer.java	Thu Apr 19 12:36:43 2012 -0400
@@ -30,6 +30,7 @@
 
 import net.sourceforge.jnlp.config.DeploymentConfiguration;
 import net.sourceforge.jnlp.runtime.Translator;
+import net.sourceforge.jnlp.util.ImageResources;
 
 /**
  * This class will provide a visual way of viewing cache.
@@ -51,6 +52,7 @@
      */
     public CacheViewer(DeploymentConfiguration config) {
         super((Frame) null, dialogTitle, true); // Don't need a parent.
+        setIconImages(ImageResources.INSTANCE.getApplicationImages());
         this.config = config;
 
         /* Prepare for adding components to dialog box */
diff -r 14dcb4fb43ac -r f13777a89e0d netx/net/sourceforge/jnlp/controlpanel/ControlPanel.java
--- a/netx/net/sourceforge/jnlp/controlpanel/ControlPanel.java	Wed Apr 18 12:28:08 2012 +0200
+++ b/netx/net/sourceforge/jnlp/controlpanel/ControlPanel.java	Thu Apr 19 12:36:43 2012 -0400
@@ -55,6 +55,7 @@
 import net.sourceforge.jnlp.runtime.Translator;
 import net.sourceforge.jnlp.security.KeyStores;
 import net.sourceforge.jnlp.security.viewer.CertificatePane;
+import net.sourceforge.jnlp.util.ImageResources;
 
 /**
  * This is the control panel for Java. It provides a GUI for modifying the
@@ -102,6 +103,7 @@
     public ControlPanel(DeploymentConfiguration config) {
         super();
         setTitle(Translator.R("CPHead"));
+        setIconImages(ImageResources.INSTANCE.getApplicationImages());
 
         this.config = config;
 
diff -r 14dcb4fb43ac -r f13777a89e0d netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java
--- a/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java	Wed Apr 18 12:28:08 2012 +0200
+++ b/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java	Thu Apr 19 12:36:43 2012 -0400
@@ -94,9 +94,6 @@
     /** update policy that controls when to check for updates */
     private static UpdatePolicy updatePolicy = UpdatePolicy.ALWAYS;
 
-    /** netx window icon */
-    private static Image windowIcon = null;
-
     /** whether initialized */
     private static boolean initialized = false;
 
@@ -188,9 +185,6 @@
         if (headless == false)
             checkHeadless();
 
-        if (!headless && windowIcon == null)
-            loadWindowIcon();
-
         if (!headless && indicator == null)
             indicator = new DefaultDownloadIndicator();
 
@@ -336,24 +330,6 @@
     }
 
     /**
-     * Returns the window icon.
-     */
-    public static Image getWindowIcon() {
-        return windowIcon;
-    }
-
-    /**
-     * Sets the window icon that is displayed in Java applications
-     * and applets instead of the default Java icon.
-     *
-     * @throws IllegalStateException if caller is not the exit class
-     */
-    public static void setWindowIcon(Image image) {
-        checkExitClass();
-        windowIcon = image;
-    }
-
-    /**
      * Returns whether the JNLP client will use any AWT/Swing
      * components.
      */
@@ -622,22 +598,6 @@
     }
 
     /**
-     * Load the window icon.
-     */
-    private static void loadWindowIcon() {
-        if (windowIcon != null)
-            return;
-
-        try {
-            windowIcon = new javax.swing.ImageIcon((new sun.misc.Launcher())
-                        .getClassLoader().getResource("net/sourceforge/jnlp/resources/netx-icon.png")).getImage();
-        } catch (Exception ex) {
-            if (JNLPRuntime.isDebug())
-                ex.printStackTrace();
-        }
-    }
-
-    /**
      * @return true if running on Windows
      */
     public static boolean isWindows() {
diff -r 14dcb4fb43ac -r f13777a89e0d netx/net/sourceforge/jnlp/runtime/JNLPSecurityManager.java
--- a/netx/net/sourceforge/jnlp/runtime/JNLPSecurityManager.java	Wed Apr 18 12:28:08 2012 +0200
+++ b/netx/net/sourceforge/jnlp/runtime/JNLPSecurityManager.java	Thu Apr 19 12:36:43 2012 -0400
@@ -350,12 +350,6 @@
             app.addWindow(w);
         }
 
-        // change coffee cup to netx for default icon
-        if (window instanceof Window)
-            for (Window w = (Window) window; w != null; w = w.getOwner())
-                if (window instanceof Frame)
-                    ((Frame) window).setIconImage(JNLPRuntime.getWindowIcon());
-
         // todo: set awt.appletWarning to custom message
         // todo: logo on with glass pane on JFrame/JWindow?
 
diff -r 14dcb4fb43ac -r f13777a89e0d netx/net/sourceforge/jnlp/security/SecurityDialog.java
--- a/netx/net/sourceforge/jnlp/security/SecurityDialog.java	Wed Apr 18 12:28:08 2012 +0200
+++ b/netx/net/sourceforge/jnlp/security/SecurityDialog.java	Thu Apr 19 12:36:43 2012 -0400
@@ -41,6 +41,7 @@
 import net.sourceforge.jnlp.runtime.JNLPRuntime;
 import net.sourceforge.jnlp.security.SecurityDialogs.AccessType;
 import net.sourceforge.jnlp.security.SecurityDialogs.DialogType;
+import net.sourceforge.jnlp.util.ImageResources;
 
 import java.awt.*;
 
@@ -98,6 +99,7 @@
     SecurityDialog(DialogType dialogType, AccessType accessType,
                 JNLPFile file, CertVerifier JarCertVerifier, X509Certificate cert, Object[] extras) {
         super();
+        setIconImages(ImageResources.INSTANCE.getApplicationImages());
         this.dialogType = dialogType;
         this.accessType = accessType;
         this.file = file;
diff -r 14dcb4fb43ac -r f13777a89e0d netx/net/sourceforge/jnlp/security/viewer/CertificateViewer.java
--- a/netx/net/sourceforge/jnlp/security/viewer/CertificateViewer.java	Wed Apr 18 12:28:08 2012 +0200
+++ b/netx/net/sourceforge/jnlp/security/viewer/CertificateViewer.java	Thu Apr 19 12:36:43 2012 -0400
@@ -51,6 +51,7 @@
 import javax.swing.UIManager;
 
 import net.sourceforge.jnlp.runtime.JNLPRuntime;
+import net.sourceforge.jnlp.util.ImageResources;
 
 public class CertificateViewer extends JDialog {
 
@@ -61,6 +62,7 @@
 
     public CertificateViewer() {
         super((Frame) null, dialogTitle, true);
+        setIconImages(ImageResources.INSTANCE.getApplicationImages());
 
         Container contentPane = getContentPane();
         contentPane.setLayout(new BorderLayout());
diff -r 14dcb4fb43ac -r f13777a89e0d netx/net/sourceforge/jnlp/util/BasicExceptionDialog.java
--- a/netx/net/sourceforge/jnlp/util/BasicExceptionDialog.java	Wed Apr 18 12:28:08 2012 +0200
+++ b/netx/net/sourceforge/jnlp/util/BasicExceptionDialog.java	Thu Apr 19 12:36:43 2012 -0400
@@ -82,6 +82,7 @@
 
         JOptionPane optionPane = new JOptionPane(mainPanel, JOptionPane.ERROR_MESSAGE);
         final JDialog errorDialog = optionPane.createDialog(R("Error"));
+        errorDialog.setIconImages(ImageResources.INSTANCE.getApplicationImages());
 
         final JPanel quickInfoPanel = new JPanel();
         BoxLayout layout = new BoxLayout(quickInfoPanel, BoxLayout.Y_AXIS);
diff -r 14dcb4fb43ac -r f13777a89e0d netx/net/sourceforge/jnlp/util/ImageResources.java
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/netx/net/sourceforge/jnlp/util/ImageResources.java	Thu Apr 19 12:36:43 2012 -0400
@@ -0,0 +1,101 @@
+/* ImageResources.java
+   Copyright (C) 2012 Red Hat, Inc.
+
+This file is part of IcedTea.
+
+IcedTea is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+IcedTea is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with IcedTea; see the file COPYING.  If not, write to the
+Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+02110-1301 USA.
+
+Linking this library statically or dynamically with other modules is
+making a combined work based on this library.  Thus, the terms and
+conditions of the GNU General Public License cover the whole
+combination.
+
+As a special exception, the copyright holders of this library give you
+permission to link this library with independent modules to produce an
+executable, regardless of the license terms of these independent
+modules, and to copy and distribute the resulting executable under
+terms of your choice, provided that you also meet, for each linked
+independent module, the terms and conditions of the license of that
+module.  An independent module is a module which is not derived from
+or based on this library.  If you modify this library, you may extend
+this exception to your version of the library, but you are not
+obligated to do so.  If you do not wish to do so, delete this
+exception statement from your version. */
+
+package net.sourceforge.jnlp.util;
+
+import java.awt.Image;
+import java.io.IOException;
+import java.io.InputStream;
+import java.util.ArrayList;
+import java.util.HashMap;
+import java.util.List;
+import java.util.Map;
+
+import javax.imageio.ImageIO;
+
+public enum ImageResources {
+
+    INSTANCE;
+
+    private static final String APPLICATION_ICON_PATH = "net/sourceforge/jnlp/resources/netx-icon.png";
+
+    private final Map<String, Image> cache = new HashMap<String, Image>();
+
+    private ImageResources() {}
+
+    /* this is for testing ONLY */
+    void clearCache() {
+        cache.clear();
+    }
+
+    /**
+     * Returns an appropriate image, or null if there are errors loading the image.
+     */
+    private Image getApplicationImage() {
+        if (cache.containsKey(APPLICATION_ICON_PATH)) {
+            return cache.get(APPLICATION_ICON_PATH);
+        }
+
+        ClassLoader cl = this.getClass().getClassLoader();
+        if (cl == null) {
+            cl = ClassLoader.getSystemClassLoader();
+        }
+
+        InputStream in = cl.getResourceAsStream(APPLICATION_ICON_PATH);
+        try {
+            Image image = ImageIO.read(in);
+            cache.put(APPLICATION_ICON_PATH, image);
+            return image;
+        } catch (IOException ioe) {
+            ioe.printStackTrace();
+            return null;
+        }
+    }
+
+    /**
+     * Returns an appropriate image, or null if there are errors loading the image.
+     */
+    public List<Image> getApplicationImages() {
+        List<Image> images = new ArrayList<Image>();
+        Image appImage = getApplicationImage();
+        if (appImage != null) {
+            images.add(appImage);
+        }
+        return images;
+    }
+
+}
diff -r 14dcb4fb43ac -r f13777a89e0d plugin/icedteanp/java/sun/applet/JavaConsole.java
--- a/plugin/icedteanp/java/sun/applet/JavaConsole.java	Wed Apr 18 12:28:08 2012 +0200
+++ b/plugin/icedteanp/java/sun/applet/JavaConsole.java	Thu Apr 19 12:36:43 2012 -0400
@@ -65,6 +65,7 @@
 
 import net.sourceforge.jnlp.config.DeploymentConfiguration;
 import net.sourceforge.jnlp.runtime.JNLPRuntime;
+import net.sourceforge.jnlp.util.ImageResources;
 
 /**
  * A simple Java console for IcedTeaPlugin
@@ -92,6 +93,7 @@
         final String logDir = JNLPRuntime.getConfiguration().getProperty(DeploymentConfiguration.KEY_USER_LOG_DIR);
 
         consoleWindow = new JFrame("Java Console");
+        consoleWindow.setIconImages(ImageResources.INSTANCE.getApplicationImages());
 
         JPanel contentPanel = new JPanel();
         contentPanel.setLayout(new GridBagLayout());
diff -r 14dcb4fb43ac -r f13777a89e0d tests/netx/unit/net/sourceforge/jnlp/util/ImageResourcesTest.java
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tests/netx/unit/net/sourceforge/jnlp/util/ImageResourcesTest.java	Thu Apr 19 12:36:43 2012 -0400
@@ -0,0 +1,71 @@
+/* ImageResourcesTest.java
+   Copyright (C) 2012 Red Hat, Inc.
+
+This file is part of IcedTea.
+
+IcedTea is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+IcedTea is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with IcedTea; see the file COPYING.  If not, write to the
+Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+02110-1301 USA.
+
+Linking this library statically or dynamically with other modules is
+making a combined work based on this library.  Thus, the terms and
+conditions of the GNU General Public License cover the whole
+combination.
+
+As a special exception, the copyright holders of this library give you
+permission to link this library with independent modules to produce an
+executable, regardless of the license terms of these independent
+modules, and to copy and distribute the resulting executable under
+terms of your choice, provided that you also meet, for each linked
+independent module, the terms and conditions of the license of that
+module.  An independent module is a module which is not derived from
+or based on this library.  If you modify this library, you may extend
+this exception to your version of the library, but you are not
+obligated to do so.  If you do not wish to do so, delete this
+exception statement from your version. */
+
+package net.sourceforge.jnlp.util;
+
+import static org.junit.Assert.assertNotNull;
+import static org.junit.Assert.assertTrue;
+
+import java.awt.Image;
+import java.util.List;
+
+import org.junit.After;
+import org.junit.Before;
+import org.junit.Test;
+
+public class ImageResourcesTest {
+
+    @Before
+    public void setUp() {
+        ImageResources.INSTANCE.clearCache();
+    }
+
+    @After
+    public void tearDown() {
+        ImageResources.INSTANCE.clearCache();
+    }
+
+    @Test
+    public void testApplicationImages() {
+        List<Image> images = ImageResources.INSTANCE.getApplicationImages();
+        assertNotNull(images);
+        assertTrue(images.size() > 0);
+        for (Image image : images) {
+            assertNotNull(image);
+        }
+    }
+}


From omajid at redhat.com  Thu Apr 19 10:50:26 2012
From: omajid at redhat.com (Omair Majid)
Date: Thu, 19 Apr 2012 13:50:26 -0400
Subject: [icedtea-web] RFC: PR918: java applet windows uses a low
	resulution black/white icon
In-Reply-To: <4F8FE40A.1020801@redhat.com>
References: <4F8ED642.30808@redhat.com> <4F8EE1E8.5070504@redhat.com>
	<4F8EE3F9.8030909@redhat.com> <4F8EEC84.80900@redhat.com>
	<4F8F84FD.8090908@redhat.com> <4F8FE40A.1020801@redhat.com>
Message-ID: <4F905062.9090502@redhat.com>

On 04/19/2012 06:08 AM, Jiri Vanek wrote:
> On 04/19/2012 05:22 AM, Omair Majid wrote:
>> On 04/18/2012 12:32 PM, Jiri Vanek wrote:
>>> On 04/18/2012 05:55 PM, Omair Majid wrote:
>>>> On 04/18/2012 11:46 AM, Jiri Vanek wrote:
>>>>
>>>> Yes, I can certainly modify ImageResources to take care of more
>>>> sizes.
>>>
>>> Then there rises question when to use which :)
>>
>> Eh? We can just set them all (using setIconImages) and let the window
>> manager pick whatever it wants! Or do you mean at places other than the
>> window icon?
> Yes this will probably make the best deal. And is it one more reason to
> hide the setting of icons (as already discussed lower). Or to use
> setIconImages already now and so prevent future refactoring.

Done.

> 
>>+ public enum ImageResources {
> 
> Wou I have never seen this :)
> I'm used for pattern like:
> class Class{
> private static final Class INSTANCE=new Class();
> 
> public static Class getInstance(){retrun INSTANCE;}
> }
> 
> But I like this enum approach. By my lack of knowledge the advantage(but
> also disadvantge compared with yours)  of above is method returning the
> singleton. But I really like your approach! Can you tell me  (just from
> curiosity) what you consider as advantages for your enum?
> 

Josh Bloch recommended this way to implement singletons in his book
"Effective Java". There is probably tons about this on the internet, but
a quick summary is available at:
http://en.wikipedia.org/wiki/Singleton_pattern#The_Enum_way

I have pushed this as:
http://icedtea.classpath.org/hg/icedtea-web/rev/f13777a89e0d

Cheers,
Omair


From ahughes at redhat.com  Thu Apr 19 11:54:09 2012
From: ahughes at redhat.com (Andrew Hughes)
Date: Thu, 19 Apr 2012 14:54:09 -0400 (EDT)
Subject: [rfc] [icedtea-web] make links
In-Reply-To: <4F8C0034.1080308@redhat.com>
Message-ID: <7b067127-4d8c-4719-b390-da84e1e191bf@zmail17.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> can I dare to ping? :)
> 
> -------- Original Message --------
> Subject: [rfc] [icedtea-web] make links
> Date: Fri, 06 Apr 2012 16:55:04 +0200
> From: Jiri Vanek <jvanek at redhat.com>
> To: IcedTea Distro List <distro-pkg-dev at openjdk.java.net>
> 
> Hi!
> 
> This is third from total of 5 patches which are introducing Tets For
> Applets[1]
> 
> This particular one is introducing  detection of browsers, linking
> the newly compiled plugin to
> detected ones and forwarding this information to testengine..
> 
> I know this linking by makefile is controversial, but it gives sense
> to me.
> Yes  - I can link the plugin with browsers manually before tests' run
> (and yes, this can be done
> once for all the runs in future), but I think this is much more
> versatile and is much more
> straightforward and much better controllable and also more
> fool-proof. The question weather to
> *UNlink* is more accurate:) ( there is no unlink right now, but
> should be easily addable if requested.
> Also when tests are run from makefile, then also all the possible
> preparation should be done from
> makefile. And this step is necessary. I have also introduced test
> weather linking is correct see
> private void testBrowser(Browser browser) calls in [2]
> 

There are two main problems I see:

1.  You're calling global-links from the main run-netx-dist-tests
target.  This means it'll get called by make check.  So you're now
requiring that test runs need root privileges and alter the installed
plugin without reverting it. I don't think this is acceptable.
I have no problem with the targets being present, but they should be
called manually.

2.  You don't provide a way of reverting to the original status quo.
I'd suggest:

	    mv -v ${HOME}/.mozilla/plugins/libjavaplugin.so ${HOME}/.mozilla/plugins/libjavaplugin.original.so && \
	    ln -s $(DESTDIR)$(libdir)/IcedTeaPlugin.so libjavaplugin.so && \

and adding the inverse to revert back to the original setup after testing.

            if [ -e ${HOME}/.mozilla/plugins/libjavaplugin.original.so ] ; \
               rm -f ${HOME}/.mozilla/plugins/libjavaplugin.so && \
               mv ${HOME}/.mozilla/plugins/libjavaplugin.original.so ${HOME}/.mozilla/plugins/libjavaplugin.so ; \
            fi ;

Other issues:

1.  Why is user-links never called from anywhere?  This is actually less
dangerous (doesn't require root) and could be automated.
2.  You don't check that ${HOME}/.mozilla/plugins exists.
3.  I think using ${HOME} as above may be safer than relying on tilde expansion by the shell.
4.  I don't think we need the messages.  They may have been useful for debugging but can now be removed.
5.  The dependencies on the new targets seem excessive.  All you need is whatever dependency ensures
the plugin has been installed.  You don't need e.g. javaws.desktop or docs.stamp because you don't use
them.
6.  On that note, surely it should use the plugin from the build directory as people tend to run "make check"
before "make install"?

> What I'm missing is When I have choose AC_CHECK_PROGS, then it does
> not support --with-val :-/ Is
> there any AC_CHECK_PROGS which allows to set with-val?
> Becasue I will probably put rather
> --with-firefox=/my/preconfiguired/firefox instead of let it use
> my default one. Although Lynks is quite good alternative during tests
> runtime :)
> Also this can be maybe intorduced as new patch later.
> 

You probably want to look at mirroring something like IT_FIND_JAVAH in IcedTea.

> Best regards J.
> 
> [1]
> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-March/017799.html
> [2]
> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120320/8ef6bdfe/browserTests-tests-0001.diff
> (btw, this page is partially corrupted - there is html test, and
> firefox is trying to translate it
> as html page :-/.. so see source rather :-/)
> 
> 
> changelog:
> 2012-04-06  Jiri Vanek <jvanek at redhat.com>
> 
> 	Added detection of installed browsers and added targets to create
> 	symbolic links from install dir
> to browsers' plugin directories. Primarily for testing purposes
> 	*Makefile.am: (clean-local) optionally delets links' stamps
> 	(stamps/user-links.stamp) with alias (links) - new target for
> 	creating symlinks for all users. One
> must be root to execute this target.
> 	(stamps/global-links.stamp) with alias (user-links) - new target for
> 	creating symlinks for logged
> user only. Because opera is missing this feature, quite useless.
> 	*configure.ac: added basic check whether and which browsers are
> 	installed
> 
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From thomas at m3y3r.de  Thu Apr 19 12:14:20 2012
From: thomas at m3y3r.de (Thomas Meyer)
Date: Thu, 19 Apr 2012 21:14:20 +0200
Subject: RFC - Reduce loading of PropertiesFile
In-Reply-To: <4F8C1644.5090001@redhat.com>
References: <1334087640.1431.26.camel@localhost.localdomain>
	<4F86D475.5020202@redhat.com>
	<1334520186.1444.43.camel@localhost.localdomain>
	<4F8C1644.5090001@redhat.com>
Message-ID: <1334862860.1435.15.camel@localhost.localdomain>

Am Montag, den 16.04.2012, 14:53 +0200 schrieb Jiri Vanek:

> >> Also I would like to suggest at least two tests with this patch
> >> 1) generate eg 1mb recently_used file and measure set some deadline how fast javaws  have to start.
> >>     The value should be failing without this patch, and  passing with this one applied. Also some
> >> real number how faster this is will be much appreciate!

Hi,

Attached are two patches that implement a unit test of
CacheLRUWrapper.load()

Some numbers of my previous optimisation patches:

No. of entries in the recently_used file = 1000
No. of calls to CacheLRUWrapper.load() = 1000

Before: Average = 3802485.0 ns
After:  Average = 44887.0 ns

> >>
> >> 2) second one will be little bit more difficult. It would be nice to test, that when recently_used
> >> is modified during javaws run, then it reloads it correctly. And so verify that this patch will not
> >> cause some regression.

Still on my todo list :-)

> >> Maybe unittest will be easier to prepare instead of 2)
> >> But I'm afraid those (or similar ) tests will be really necessary.
> >


>  > diff -r 17f9e4e1ac6d netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java
> --- a/netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java	Wed Apr 11 10:19:17 2012 +0200
> +++ b/netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java	Mon Apr 16 14:08:18 2012 +0200
> @@ -108,11 +108,11 @@
>        * Update map for keeping track of recently used items.
>        */
>       public synchronized void load() {
> -        cacheOrder.load();
> +        boolean loaded = cacheOrder.load();
>           /*
>            * clean up possibly corrupted entries
>            */
> -        if (checkData()) {
> +        if (loaded == true && checkData()) {
> 
>  > As already told above, Unless there is some particular reason, please avoid boolean comparsion with true/false

this is actually fixed in this patch. the attached patch file consists
actually of two diffs that needs to be applied to the icedtea-web repo
in order. mercurial doesn't let me rewrite the commit history, so I just
exported all revisions in one file. that's actually a bit confusing,
when you only look at the patch file.


> 
>               if (JNLPRuntime.isDebug()) {
>                   new LruCacheException().printStackTrace();
>               }
> @@ -125,7 +125,7 @@
>       /**
>        * check content of cacheOrder and remove invalid/corrupt entries
>        *
> -     * @return true, if cache was coruupted and affected entry removed
> +     * @return true, if cache was corrupted and affected entry removed
>        */
>       private boolean checkData () {
>           boolean modified = false;
> diff -r 17f9e4e1ac6d netx/net/sourceforge/jnlp/util/PropertiesFile.java
> --- a/netx/net/sourceforge/jnlp/util/PropertiesFile.java	Wed Apr 11 10:19:17 2012 +0200
> +++ b/netx/net/sourceforge/jnlp/util/PropertiesFile.java	Mon Apr 16 14:08:18 2012 +0200
> @@ -104,24 +107,38 @@
>        * Ensures that the file backing these properties has been
>        * loaded; call this method before calling any method defined by
>        * a superclass.
> +     *
> +     * @return true, if file was (re-)loaded
> +     *         false, if file was still current
>        */
> -    public void load() {
> +    public boolean load() {
> +
> +        if (!file.exists())
> +            return false;
> 
>  > this is really nitpick and I'm sorry for it, but current code guidelines dictate brackets after if

okay, will fix this, too.

> @@ -131,12 +148,16 @@
>           if (!loaded)
>               return; // nothing could have changed so save unnecessary load/save
> 
> -        OutputStream s = null;
> +        FileOutputStream s = null;
>           try {
>               try {
>                   file.getParentFile().mkdirs();
>                   s = new FileOutputStream(file);
>                   store(s, header);
> +
> +                // fsync()
> +                s.getChannel().force(true);
> +                lastStore = file.lastModified();
>  > Very well :) I have never seen this before, so I hope you know what you are doing:) (but looks correct from javadoc)

I'm not sure if a flush() is needed before the fsync() aka.
s.getChannel().force(true);
Internet suggest a flush() is needed. I may add this. Suggestions?

thomas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch1.diff
Type: text/x-patch
Size: 1261 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120419/cca3637c/patch1.diff 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch2.diff
Type: text/x-patch
Size: 4186 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120419/cca3637c/patch2.diff 

From jvanek at redhat.com  Fri Apr 20 01:05:41 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Fri, 20 Apr 2012 10:05:41 +0200
Subject: [RFC][icedtea-web] Test for regression of ServiceManager not
	setup correctly
In-Reply-To: <4F5E5F3F.4010302@redhat.com>
References: <4F3ED5DB.6000006@redhat.com> <4F3EDDE3.4020705@redhat.com>
	<4F43EB54.4070000@redhat.com> <4F5E261A.3030003@redhat.com>
	<4F5E5F3F.4010302@redhat.com>
Message-ID: <4F9118D5.6080902@redhat.com>

>>>> In general, am not sure how good these applet tests might be. We know
>>>> that applets run under javaws use different code paths from applets run
>>>> under a browser. Still it's better to have a few tests than none.
>>>
>> As mentioned above in-html tests will be necessary to be added when
>> browser-testing will be pushed.
>>
>
> Will do.
>
>>
>>


Just reminder O:)

J.


From jvanek at redhat.com  Fri Apr 20 02:32:44 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Fri, 20 Apr 2012 11:32:44 +0200
Subject: [RFC][icedtea-web] Fix for single instance service with applets
	using	jnlp_href
In-Reply-To: <4F5E2C2F.7090603@redhat.com>
References: <4F2849F3.2030003@redhat.com> <4F5DD2F8.8000904@redhat.com>
	<4F5E2C2F.7090603@redhat.com>
Message-ID: <4F912D3C.9080804@redhat.com>

>>
>
> Yeah, it was a confusing service to wrap my head around. :S
>
> Right now, SingleInstanceService is available to use from applets/applications run by javaws. I am
> trying to port this over to the plugin so that when jnlp_href is used, applets have access to it.
>
> The point of the service itself is to only let one instance of an applet run at a time. There's a
> catch to running another instance of the applet though. While the first one is running, it is setup
> with a listener for later instances to use. The idea is that the second instance can communicate
> with the running instance, passing along some args to be handled by the listener, and then exit.
> When you run another instance of the applet, icedtea-web is supposed to recognize this as the second
> instance and pass on a list of arguments provided by the dev. See the API for
> SingleInstanceListener[1] for the methods. I think the following signleapp example[2] might help you
> too.
>
> Here's an example run path:
>
> 1. Start single instance app. The dev has set it up to handle params accordingly, say to spit it out
> on the screen to log.
> 2. IcedTea-Web sets up a single instance server to keep track of the instance running.
> 3. The second app is run, args are passed in by the dev again. Let's say they are the current
> date/time.
> 4. IcedTea-Web notices the second app is a second instance of the first one and checks that the
> first one's server is still running, then denies init of the second applet. The second instance's
> args are taken and passed along to the first instance's newActivation(String[] args) method.
> 5. Dev's newActivation method reacts accordingly.
>
> I hope the example[2] helps clear up any doubts I have not covered but please ask if it doesn't!
>
>>> Attached is a patch to fix SingleInstanceService to work when applets
>>> use jnlp_href.
>>>
>>> If a single instance exists, it'll throw a fatal exception for the
>>> second applet and stop running it. The applet passes the args along
>>> while checking. However, proprietary documentation is unclear about
>>> which args are passed so for now I have left it as a FIXME until
>>> that's cleared up.
>> I believe applets parameters inside tag/jnlp descriptor are correct way.
>
> These args I was referring to are from the second instance being run so we're talking about
> different things here. =) Please see above.
>
Well well... It was digging to find what this should be doing, and it looks tome like it is not 
doing something.

Can I ask for large set of reproducers?

two same javaws applications runnig together/ two same javaws applications running as SingleInstance 
and passing params / two different javaws  running together/ two different javaws applications 
running as SingleInstance and "passing" params

two same applets-in-javaws applications runig together/ two same applets-in-javaws applications 
running as SingleInstance and passing params / two different applets-in-javaws  running together/ 
two different applets-in-javaws applications running as SingleInstance and "passing" params

two same applets-in-browser  running together/ two same applets-in-javaws applications running as 
SingleInstance and passing params /two different applets-in-browser  running together/ two different 
applets-in-javaws applications running as SingleInstance and "passing" params



It will need similar approach as I have used in   xfork test, but better then sleep use StdOut use 
contentReader listeners and do not wait for timeout (as it really delays 	test runs)


The patch itself looks ok, and if will pass above tests, then it is ok for head. The only  issue is 
passing params to applet. Yes, specification is silent in this issue, but I'm against String[0] (at 
least it is hard to test!:)). My idea here is to pass new String{key1,value1, 
key2,value2...keyn,valuen}. Better then nothing I believe.

Thanx for hard work!
   J.




From jvanek at redhat.com  Fri Apr 20 03:06:58 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Fri, 20 Apr 2012 12:06:58 +0200
Subject: [RFC][icedtea-web] Fix handling absolute paths passed into
	jnlp_href's value.
In-Reply-To: <4F5E69D6.9060401@redhat.com>
References: <4F5E69D6.9060401@redhat.com>
Message-ID: <4F913542.5050500@redhat.com>

On 03/12/2012 10:25 PM, Danesh Dadachanji wrote:
> Hi,
>
> The Knuddels test applet[1] uses an absolute path to the JNLP when using jnlp_href. Right now we
> assume it's a relative path and take the document base (i.e. the URL of the dir in which HTML file
> is located) concatenated with the value of jnlp_href for the new URL.
>
> The attached patch updates PluginBridge to handle absolute paths to the JNLP. I simply used the
> document base as the context to create a new URL. Based on the javadoc for this, if jnlp_href's
> value is not a properly formed URL, it will default to using the document base's URL as the base URL
> and append the relative part (value of jnlp_href) to the end of it.
>
> The URL constructor also handles relative paths so if codebase="../example.jnlp", the constructor
> will act accordingly and remove a dir if possible.
>
> +2012-03-09 Danesh Dadachanji <ddadacha at redhat.com>
> +
> + Fix to handle absolute paths passed into jnlp_href's value.
> + * netx/net/sourceforge/jnlp/PluginBridge.java
> + (PluginBridge): Use the document base as a context for the URL
> + being initialized by jnlp_href's value. This will automatically handle
> + relative and absolute URL paths.
> +
>
> Any comments? Can I push this to HEAD?
>
> NOTE: [1] still won't work because it has invalid XML. However you should see that it can now find
> the JNLP at the correct URL as opposed to
>
> java.io.IOException: http://chat.knuddels.de/http://www.knuddels.de/applet.jnlp[...]
>
> Regards,
> Danesh
>
> [1] www.knuddels.de:8080/index.html?v=90aez&c=7

This looks ok to me. Can you add unit tests please?

(feel free to some refactoring if necessary for testing purposes)


J.


From jvanek at redhat.com  Fri Apr 20 03:25:19 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Fri, 20 Apr 2012 12:25:19 +0200
Subject: RFC - Reduce loading of PropertiesFile
In-Reply-To: <1334862860.1435.15.camel@localhost.localdomain>
References: <1334087640.1431.26.camel@localhost.localdomain>
	<4F86D475.5020202@redhat.com>
	<1334520186.1444.43.camel@localhost.localdomain>
	<4F8C1644.5090001@redhat.com>
	<1334862860.1435.15.camel@localhost.localdomain>
Message-ID: <4F91398F.5080801@redhat.com>

On 04/19/2012 09:14 PM, Thomas Meyer wrote:
> Am Montag, den 16.04.2012, 14:53 +0200 schrieb Jiri Vanek:
>
>>>> Also I would like to suggest at least two tests with this patch
>>>> 1) generate eg 1mb recently_used file and measure set some deadline how fast javaws  have to start.
>>>>      The value should be failing without this patch, and  passing with this one applied. Also some
>>>> real number how faster this is will be much appreciate!
>
> Hi,
>
> Attached are two patches that implement a unit test of
> CacheLRUWrapper.load()
>
> Some numbers of my previous optimisation patches:
>
> No. of entries in the recently_used file = 1000
> No. of calls to CacheLRUWrapper.load() = 1000
>
> Before: Average = 3802485.0 ns
> After:  Average = 44887.0 ns
>
>>>>
>>>> 2) second one will be little bit more difficult. It would be nice to test, that when recently_used
>>>> is modified during javaws run, then it reloads it correctly. And so verify that this patch will not
>>>> cause some regression.
>
> Still on my todo list :-)
>
>>>> Maybe unittest will be easier to prepare instead of 2)
>>>> But I'm afraid those (or similar ) tests will be really necessary.
>>>
>
>
>>   >  diff -r 17f9e4e1ac6d netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java
>> --- a/netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java	Wed Apr 11 10:19:17 2012 +0200
>> +++ b/netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java	Mon Apr 16 14:08:18 2012 +0200
>> @@ -108,11 +108,11 @@
>>         * Update map for keeping track of recently used items.
>>         */
>>        public synchronized void load() {
>> -        cacheOrder.load();
>> +        boolean loaded = cacheOrder.load();
>>            /*
>>             * clean up possibly corrupted entries
>>             */
>> -        if (checkData()) {
>> +        if (loaded == true&&  checkData()) {
>>
>>   >  As already told above, Unless there is some particular reason, please avoid boolean comparsion with true/false
>
> this is actually fixed in this patch. the attached patch file consists
> actually of two diffs that needs to be applied to the icedtea-web repo
> in order. mercurial doesn't let me rewrite the commit history, so I just
> exported all revisions in one file. that's actually a bit confusing,
> when you only look at the patch file.
>
>
>>
>>                if (JNLPRuntime.isDebug()) {
>>                    new LruCacheException().printStackTrace();
>>                }
>> @@ -125,7 +125,7 @@
>>        /**
>>         * check content of cacheOrder and remove invalid/corrupt entries
>>         *
>> -     * @return true, if cache was coruupted and affected entry removed
>> +     * @return true, if cache was corrupted and affected entry removed
>>         */
>>        private boolean checkData () {
>>            boolean modified = false;
>> diff -r 17f9e4e1ac6d netx/net/sourceforge/jnlp/util/PropertiesFile.java
>> --- a/netx/net/sourceforge/jnlp/util/PropertiesFile.java	Wed Apr 11 10:19:17 2012 +0200
>> +++ b/netx/net/sourceforge/jnlp/util/PropertiesFile.java	Mon Apr 16 14:08:18 2012 +0200
>> @@ -104,24 +107,38 @@
>>         * Ensures that the file backing these properties has been
>>         * loaded; call this method before calling any method defined by
>>         * a superclass.
>> +     *
>> +     * @return true, if file was (re-)loaded
>> +     *         false, if file was still current
>>         */
>> -    public void load() {
>> +    public boolean load() {
>> +
>> +        if (!file.exists())
>> +            return false;
>>
>>   >  this is really nitpick and I'm sorry for it, but current code guidelines dictate brackets after if
>
> okay, will fix this, too.
>
>> @@ -131,12 +148,16 @@
>>            if (!loaded)
>>                return; // nothing could have changed so save unnecessary load/save
>>
>> -        OutputStream s = null;
>> +        FileOutputStream s = null;
>>            try {
>>                try {
>>                    file.getParentFile().mkdirs();
>>                    s = new FileOutputStream(file);
>>                    store(s, header);
>> +
>> +                // fsync()
>> +                s.getChannel().force(true);
>> +                lastStore = file.lastModified();
>>   >  Very well :) I have never seen this before, so I hope you know what you are doing:) (but looks correct from javadoc)
>
> I'm not sure if a flush() is needed before the fsync() aka.
> s.getChannel().force(true);
> Internet suggest a flush() is needed. I may add this. Suggestions?
>

Only naive one - flush() fill certainly not make thinks worse. So I'm for.

Nice work till now! Let's wait for last test and looking forward for push!

Best regards, J.




From jvanek at redhat.com  Fri Apr 20 04:38:18 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Fri, 20 Apr 2012 13:38:18 +0200
Subject: [RFC][ICEDTEA-WEB] reproducer for pr955
Message-ID: <4F914AAA.3080108@redhat.com>

2012-04-20 Jiri Vanek<jvanek at redhat.com>

	Reproducer  for PR955
	* tests/jnlp_tests/simple/simpletest1/resources/simpletest1Localised.jnlp:
	New file, have localised information tags with not all required fields.
	* tests/jnlp_tests/simple/simpletest1/testcases/SimpleTest1Test.java:
	(testSimpletest1lunchWithLocalisedInformation) new testacese for above file

Hi! This simple test is reproducing behaviour of pr955.
However if it is doing the right way or not is discussable. Specification is clear that those 
elements are required. But proprietary plugin looks like taking default values from not-localised 
default one.

So what do you think?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr955Reproducer.diff
Type: text/x-patch
Size: 5149 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120420/3ddc6da8/pr955Reproducer.diff 

From jvanek at redhat.com  Fri Apr 20 05:00:35 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Fri, 20 Apr 2012 14:00:35 +0200
Subject: RFC - Reduce loading of PropertiesFile
In-Reply-To: <1334862860.1435.15.camel@localhost.localdomain>
References: <1334087640.1431.26.camel@localhost.localdomain>
	<4F86D475.5020202@redhat.com>
	<1334520186.1444.43.camel@localhost.localdomain>
	<4F8C1644.5090001@redhat.com>
	<1334862860.1435.15.camel@localhost.localdomain>
Message-ID: <4F914FE3.2030109@redhat.com>

On 04/19/2012 09:14 PM, Thomas Meyer wrote:

>
> patch1.diff
>
>
> # HG changeset patch
> # User Thomas Meyer<thomas at m3y3r.de>
> # Date 1334859522 -7200
> # Node ID e750944c8d66bbab0801e7490303eef26b689df3
> # Parent  4a35862de3fc26a9e1cdfb66fd7b6c750f18371b
> Enable JNLPRuntime class to run in headless mode
>
> diff -r 4a35862de3fc -r e750944c8d66 netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java
> --- a/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java	Thu Apr 19 20:02:40 2012 +0200
> +++ b/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java	Thu Apr 19 20:18:42 2012 +0200
> @@ -199,12 +199,14 @@
>           ServiceManager.setServiceManagerStub(new XServiceManagerStub()); // ignored if we're running under Web Start
>
>           policy = new JNLPPolicy();
> -        security = new JNLPSecurityManager(); // side effect: create JWindow
> -
> -        try {
> -            UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
> -        } catch (Exception e) {
> -            // ignore it
> +        if (!headless) {
> +            security = new JNLPSecurityManager(); // side effect: create JWindow
> +
> +            try {
> +                UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
> +            } catch (Exception e) {
> +                // ignore it
> +            }
>           }
>
>           doMainAppContextHacks();
>
>
hmhm. This looks un-relevant to original issue. What is motivation? Can you poist it in new patch?

> patch2.diff
>
>
> # HG changeset patch
> # User Thomas Meyer<thomas at m3y3r.de>
> # Date 1334861615 -7200
> # Node ID b814c44a1613b27f478adfbaed9c2ed1be43ba51
> # Parent  e750944c8d66bbab0801e7490303eef26b689df3
> Add unit test for CacheLRUWrapper.load() optimisation
>
> diff -r e750944c8d66 -r b814c44a1613 tests/netx/unit/net/sourceforge/jnlp/cache/CacheLRUWrapperTest.java
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tests/netx/unit/net/sourceforge/jnlp/cache/CacheLRUWrapperTest.java	Thu Apr 19 20:53:35 2012 +0200
...
> +
> +        // wait more than 100ms for noLoops = 1000 and noEntries=1000 is bad
> +        assertTrue(avg<  100 * 1000);

Please add explanation string
Something like
assertTrue("recently_used file must be loaded under 100000ns, was  in "+avg,avg<  100 * 1000);

> +
> +        clw.unlock();
> +    }
> +
> +}
>

Thanx again!


From thomas at m3y3r.de  Fri Apr 20 06:01:01 2012
From: thomas at m3y3r.de (Thomas Meyer)
Date: Fri, 20 Apr 2012 15:01:01 +0200
Subject: RFC - Reduce loading of PropertiesFile
In-Reply-To: <4F914FE3.2030109@redhat.com>
References: <1334087640.1431.26.camel@localhost.localdomain>
	<4F86D475.5020202@redhat.com>
	<1334520186.1444.43.camel@localhost.localdomain>
	<4F8C1644.5090001@redhat.com>
	<1334862860.1435.15.camel@localhost.localdomain>
	<4F914FE3.2030109@redhat.com>
Message-ID: <20120420150101.14915dxboe6rewb1@webmail.your-server.de>


Zitat von Jiri Vanek <jvanek at redhat.com>:

> On 04/19/2012 09:14 PM, Thomas Meyer wrote:
>
>>
>> patch1.diff
>>
>>
>> # HG changeset patch
>> # User Thomas Meyer<thomas at m3y3r.de>
>> # Date 1334859522 -7200
>> # Node ID e750944c8d66bbab0801e7490303eef26b689df3
>> # Parent  4a35862de3fc26a9e1cdfb66fd7b6c750f18371b
>> Enable JNLPRuntime class to run in headless mode
>>
>> diff -r 4a35862de3fc -r e750944c8d66  
>> netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java
>> --- a/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java	Thu Apr 19  
>> 20:02:40 2012 +0200
>> +++ b/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java	Thu Apr 19  
>> 20:18:42 2012 +0200
>> @@ -199,12 +199,14 @@
>>          ServiceManager.setServiceManagerStub(new  
>> XServiceManagerStub()); // ignored if we're running under Web Start
>>
>>          policy = new JNLPPolicy();
>> -        security = new JNLPSecurityManager(); // side effect:  
>> create JWindow
>> -
>> -        try {
>> -             
>> UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
>> -        } catch (Exception e) {
>> -            // ignore it
>> +        if (!headless) {
>> +            security = new JNLPSecurityManager(); // side effect:  
>> create JWindow
>> +
>> +            try {
>> +                 
>> UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
>> +            } catch (Exception e) {
>> +                // ignore it
>> +            }
>>          }
>>
>>          doMainAppContextHacks();
>>
>>
> hmhm. This looks un-relevant to original issue. What is motivation?  
> Can you poist it in new patch?

without this path the unit test fails in/after a call to  
JNLPRuntime.initialize() with a StackOverflowException.

my solution was to disable the SecurityManager for headless mode. this  
made my unit test work.
I'm not sure if this is the correct thing to do here! Help appriciated!

thomas




From ptisnovs at icedtea.classpath.org  Fri Apr 20 06:20:21 2012
From: ptisnovs at icedtea.classpath.org (ptisnovs at icedtea.classpath.org)
Date: Fri, 20 Apr 2012 13:20:21 +0000
Subject: /hg/gfx-test: * src/org/gfxtest/framework/PrintingTest.java:
Message-ID: <hg.f72558a932b2.1334928021.-6248649288953172555@icedtea.classpath.org>

changeset f72558a932b2 in /hg/gfx-test
details: http://icedtea.classpath.org/hg/gfx-test?cmd=changeset;node=f72558a932b2
author: Pavel Tisnovsky <ptisnovs at redhat.com>
date: Fri Apr 20 15:22:51 2012 +0200

	* src/org/gfxtest/framework/PrintingTest.java:
	Fixed computations of image size based on page properties.
	Refactoring, added JavaDoc.


diffstat:

 ChangeLog                                   |   6 +
 src/org/gfxtest/framework/PrintingTest.java |  98 ++++++++++++++++++++++++----
 2 files changed, 90 insertions(+), 14 deletions(-)

diffs (191 lines):

diff -r a630b16209f8 -r f72558a932b2 ChangeLog
--- a/ChangeLog	Thu Apr 19 17:39:58 2012 +0200
+++ b/ChangeLog	Fri Apr 20 15:22:51 2012 +0200
@@ -1,3 +1,9 @@
+2012-04-20  Pavel Tisnovsky  <ptisnovs at redhat.com>
+
+	* src/org/gfxtest/framework/PrintingTest.java:
+	Fixed computations of image size based on page properties.
+	Refactoring, added JavaDoc.
+
 2012-04-19  Pavel Tisnovsky  <ptisnovs at redhat.com>
 
 	* src/org/gfxtest/testsuites/ClippingPathByRectangleShape.java:
diff -r a630b16209f8 -r f72558a932b2 src/org/gfxtest/framework/PrintingTest.java
--- a/src/org/gfxtest/framework/PrintingTest.java	Thu Apr 19 17:39:58 2012 +0200
+++ b/src/org/gfxtest/framework/PrintingTest.java	Fri Apr 20 15:22:51 2012 +0200
@@ -48,12 +48,40 @@
 import java.lang.reflect.InvocationTargetException;
 import java.lang.reflect.Method;
 
+
+
+/**
+ * Implementation of the framework used to prepare and run printing tests.
+ * Output of such tests are stored in a PostScript file which could be rendered
+ * using GhostScript or other implementation of PostScript language.
+ * 
+ * @author Pavel Tisnovsky
+ */
 public class PrintingTest implements Printable
 {
+    /**
+     * Used to run the selected test
+     */
     private GfxTest gfxTest;
+
+    /**
+     * Method of selected test which should be called
+     */
     private Method method;
+
+    /**
+     * Test result
+     */
     private TestResult result = null;
 
+    /**
+     * Constructor which configures printing test framework.
+     * 
+     * @param gfxTest
+     *            used to run the selected test
+     * @param method
+     *            method of selected test which should be called
+     */
     public PrintingTest(GfxTest gfxTest, Method method)
     {
         setGfxTest(gfxTest);
@@ -61,6 +89,8 @@
     }
 
     /**
+     * Get the current value of attribute method.
+     *
      * @return the method
      */
     public Method getMethod()
@@ -69,6 +99,8 @@
     }
 
     /**
+     * Set a new value of a attribute method.
+     *
      * @param method the method to set
      */
     public void setMethod(Method method)
@@ -77,6 +109,8 @@
     }
 
     /**
+     * Get the current value of attribute result.
+     *
      * @return the result
      */
     public TestResult getResult()
@@ -85,6 +119,8 @@
     }
 
     /**
+     * Set a new value of a attribute method.
+     *
      * @param result the result to set
      */
     public void setResult(TestResult result)
@@ -93,6 +129,8 @@
     }
 
     /**
+     * Get the current value of attribute gfxTest.
+     *
      * @return the gfxTest
      */
     public GfxTest getGfxTest()
@@ -101,6 +139,8 @@
     }
 
     /**
+     * Set a new value of a attribute gfxTest.
+     *
      * @param gfxTest the gfxTest to set
      */
     public void setGfxTest(GfxTest gfxTest)
@@ -108,19 +148,23 @@
         this.gfxTest = gfxTest;
     }
 
+    /**
+     * Prints the page at the specified index into the specified Graphics context in the specified format.
+     */
     @Override
     public int print(Graphics graphics, PageFormat pageFormat, int pageIndex) throws PrinterException
     {
-        if (pageIndex > 0) { /* We have only one page, and 'page' is zero-based */
+        /* we have only one page, and 'page' is zero-based */
+        if (pageIndex > 0) { 
             return NO_SUCH_PAGE;
         }
- 
-        /* Origin (0,0) is typically outside the imageable area, so we must
-         * translate by the X and Y values in the PageFormat to avoid clipping
-         */
+
         Graphics2D gc = (Graphics2D)graphics;
-        gc.translate(pageFormat.getImageableX(), pageFormat.getImageableY());
-        TestImage image = new TestImage(pageFormat.getWidth(), pageFormat.getHeight());
+        translateCoordinateSystem(pageFormat, gc);
+
+        /* create test image with the width and height based of page format */
+        TestImage image = createTestImage(pageFormat);
+
         try
         {
             setResult((TestResult) this.method.invoke(getGfxTest(), new Object[] { image, gc }));
@@ -141,15 +185,41 @@
             setResult(TestResult.ERROR);
         }
 
-        /*
-        graphics.setColor(Color.RED);
-        graphics.drawLine(0, 0, (int)pageFormat.getWidth(), (int)pageFormat.getHeight());
-        graphics.drawLine((int)pageFormat.getWidth(), 0, 0, (int)pageFormat.getHeight());
-
-        graphics.drawString("Hello world!", 100, 100);
-        */
         /* tell the caller that this page is part of the printed document */
         return PAGE_EXISTS;
     }
 
+    /**
+     * Translate coordinate system used to put graphics object into a page.
+     * 
+     * Origin (0,0) is typically outside the imageable area, so we must
+     * translate by the X and Y values in the PageFormat to avoid clipping
+     * 
+     * @param pageFormat
+     *            object containing the size and orientation of a page to be
+     *            printed.
+     * @param gc graphics context
+     */
+    private void translateCoordinateSystem(PageFormat pageFormat, Graphics2D gc)
+    {
+        gc.translate(pageFormat.getImageableX() * 2, pageFormat.getImageableY() * 2);
+    }
+
+    /**
+     * Create test image with the width and height based of page format.
+     * 
+     * @param pageFormat
+     *            object containing the size and orientation of a page to be
+     *            printed.
+     * @return object representing raster image on which shapes are rendered.
+     */
+    private TestImage createTestImage(PageFormat pageFormat)
+    {
+        final double width = pageFormat.getImageableWidth();
+        final double height = pageFormat.getImageableHeight();
+        final double xoffset = pageFormat.getImageableX();
+        final double yoffset = pageFormat.getImageableY();
+        return new TestImage(width - xoffset, height - yoffset);
+    }
+
 }


From ptisnovs at icedtea.classpath.org  Fri Apr 20 07:26:00 2012
From: ptisnovs at icedtea.classpath.org (ptisnovs at icedtea.classpath.org)
Date: Fri, 20 Apr 2012 14:26:00 +0000
Subject: /hg/release/icedtea6-1.11: NEWS: Mention bugfix PR797 (the same ...
Message-ID: <hg.acc48a156236.1334931960.-53431993501496595@icedtea.classpath.org>

changeset acc48a156236 in /hg/release/icedtea6-1.11
details: http://icedtea.classpath.org/hg/release/icedtea6-1.11?cmd=changeset;node=acc48a156236
author: ptisnovs
date: Fri Apr 20 17:25:45 2012 +0200

	NEWS: Mention bugfix PR797 (the same as bugfig RH789154).


diffstat:

 ChangeLog |  4 ++++
 NEWS      |  1 +
 2 files changed, 5 insertions(+), 0 deletions(-)

diffs (22 lines):

diff -r d1bcc17048f3 -r acc48a156236 ChangeLog
--- a/ChangeLog	Wed Apr 18 18:47:34 2012 +0200
+++ b/ChangeLog	Fri Apr 20 17:25:45 2012 +0200
@@ -1,3 +1,7 @@
+2012-04-20  Pavel Tisnovsky  <ptisnovs at redhat.com>
+
+	* NEWS: Mention bugfix PR797 (the same as bugfig RH789154).
+
 2012-04-18  Pavel Tisnovsky  <ptisnovs at redhat.com>
 
 	* patches/openjdk/6792400-Avoid_loading_Normalizer_resources.patch:
diff -r d1bcc17048f3 -r acc48a156236 NEWS
--- a/NEWS	Wed Apr 18 18:47:34 2012 +0200
+++ b/NEWS	Fri Apr 20 17:25:45 2012 +0200
@@ -14,6 +14,7 @@
 
 * Bug fixes
   - RH789154: javac error messages no longer contain the full path to the offending file:
+  - PR797: Compiler error message does not display entire file name and path
   - PR881: Sign tests (wsse.policy.basic) failures with OpenJDK6
 * Backports
   - S6792400: Avoid loading of Normalizer resources for simple uses


From ptisnovs at icedtea.classpath.org  Fri Apr 20 07:30:50 2012
From: ptisnovs at icedtea.classpath.org (ptisnovs at icedtea.classpath.org)
Date: Fri, 20 Apr 2012 14:30:50 +0000
Subject: /hg/icedtea6: NEWS: Mention bugfix PR797 (the same as bugfig RH7...
Message-ID: <hg.e611555d93cb.1334932250.2873452341184383832@icedtea.classpath.org>

changeset e611555d93cb in /hg/icedtea6
details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=e611555d93cb
author: ptisnovs
date: Fri Apr 20 17:30:17 2012 +0200

	NEWS: Mention bugfix PR797 (the same as bugfig RH789154).


diffstat:

 ChangeLog |  4 ++++
 NEWS      |  1 +
 2 files changed, 5 insertions(+), 0 deletions(-)

diffs (22 lines):

diff -r 4826fae07d72 -r e611555d93cb ChangeLog
--- a/ChangeLog	Thu Mar 29 18:18:31 2012 +0200
+++ b/ChangeLog	Fri Apr 20 17:30:17 2012 +0200
@@ -1,3 +1,7 @@
+2012-04-20  Pavel Tisnovsky  <ptisnovs at redhat.com>
+
+	* NEWS: Mention bugfix PR797 (the same as bugfig RH789154).
+
 2012-03-29  Pavel Tisnovsky  <ptisnovs at redhat.com>
 
 	* patches/revert-6885123.patch: Removed to fix
diff -r 4826fae07d72 -r e611555d93cb NEWS
--- a/NEWS	Thu Mar 29 18:18:31 2012 +0200
+++ b/NEWS	Fri Apr 20 17:30:17 2012 +0200
@@ -17,6 +17,7 @@
   - PR886: 6-1.11.1 fails to build CACAO on ppc
   - PR881: Sign tests (wsse.policy.basic) failures with OpenJDK6
   - RH789154: javac error messages no longer contain the full path to the offending file:
+  - PR797: Compiler error message does not display entire file name and path
 * Backports
   - S6706974: Add krb5 test infrastructure
   - S6764553: com.sun.org.apache.xml.internal.security.utils.IdResolver is not thread safe


From meyert at icedtea.classpath.org  Fri Apr 20 08:20:16 2012
From: meyert at icedtea.classpath.org (meyert at icedtea.classpath.org)
Date: Fri, 20 Apr 2012 15:20:16 +0000
Subject: /hg/icedtea-web: Spelling fixes
Message-ID: <hg.a1c138829627.1334935216.8643924302249223276@icedtea.classpath.org>

changeset a1c138829627 in /hg/icedtea-web
details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=a1c138829627
author: Thomas Meyer <thomas at m3y3r.de>
date: Fri Apr 20 17:17:59 2012 +0200

	Spelling fixes


diffstat:

 tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java |  106 ++++-----
 1 files changed, 52 insertions(+), 54 deletions(-)

diffs (373 lines):

diff -r f13777a89e0d -r a1c138829627 tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java
--- a/tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java	Thu Apr 19 12:36:43 2012 -0400
+++ b/tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java	Fri Apr 20 17:17:59 2012 +0200
@@ -54,12 +54,10 @@
 import java.net.ServerSocket;
 import java.net.Socket;
 import java.net.SocketException;
-import java.net.URI;
 import java.net.URL;
 import java.net.URLDecoder;
 import java.util.ArrayList;
 import java.util.HashSet;
-import java.util.Iterator;
 import java.util.List;
 import java.util.Set;
 import java.util.StringTokenizer;
@@ -68,16 +66,16 @@
 
 /**
  *
- * This class provides access to virtual server and stuff arround.
- * It can find unoccupied port, start server, provides its singleton instantion, lunch paralel instantions,
- * read location of installed (tested javaws) see javaws.build.bin java poperty,
- * location of server www root on filesystem (see test.server.dir java property),
+ * This class provides access to virtual server and stuff around.
+ * It can find unoccupied port, start server, provides its singleton instantiation, lunch parallel instantiations,
+ * read location of installed (tested javaws) see javaws.build.bin java property,
+ * location of server www root on file system (see test.server.dir java property),
  * stubs for lunching javaws and for locating resources and read resources.
  *
  * It can also execute processes with timeout (@see PROCESS_TIMEOUT) (used during lunching javaws)
- * Some protected apis are exported because public clases in this package are put to be tested by makefile.
+ * Some protected apis are exported because public classes in this package are put to be tested by makefile.
  *
- * There are inclued tescases which show some basic usages.
+ * There are included test cases which show some basic usages.
  *
  *
  */
@@ -85,11 +83,11 @@
 
     public static final long NANO_TIME_DELIMITER=1000000l;
     /**
-     * java property which value containig path to default (makefile by) directory with deployed resources
+     * java property which value containing path to default (makefile by) directory with deployed resources
      */
     public static final String TEST_SERVER_DIR = "test.server.dir";
     /**
-     * java property which value containig path to installed (makefile by) javaws binary
+     * java property which value containing path to installed (makefile by) javaws binary
      */
     public static final String JAVAWS_BUILD_BIN = "javaws.build.bin";
     /** property to set the different then default browser
@@ -97,11 +95,11 @@
     public static final String USED_BROWSER_COMMAND = "used.browser.command";
     public static final String DEFAULT_LOCALHOST_NAME = "localhost";
     /**
-     * server instance singeton
+     * server instance singleton
      */
     private static ServerLauncher server;
     /**
-     * inner version if engine
+     * inner version of engine
      */
     private static final String version = "4";
     /**
@@ -110,7 +108,7 @@
      */
     public static int READ_TIMEOUT = 1000;
     /**
-     * timeout in ms to let process to finish, before assasin wil kill it.
+     * timeout in ms to let process to finish, before assassin will kill it.
      * This can be changed in runtime, but will affect all following tasks
      */
     public static long PROCESS_TIMEOUT = 20 * 1000;//ms
@@ -120,10 +118,10 @@
     private static Set<Thread> terminated = new HashSet<Thread>();
 
     /**
-     * main method of thos class prints out random free port
+     * main method of this class prints out random free port
      * or runs server
      * param "port" prints out the port
-     * nothing or number will run  sefrver on random(or on number specified)
+     * nothing or number will run server on random(or on number specified)
      * port in -Dtest.server.dir
      */
     public static void main(String[] args) throws Exception {
@@ -147,8 +145,8 @@
     /**
      * utility method to find random free port
      *
-     * @return - foud random free port
-     * @throws IOException - if socket can't be openned or no free port exists
+     * @return - found random free port
+     * @throws IOException - if socket can't be opened or no free port exists
      */
     public static int findFreePort()
             throws IOException {
@@ -160,7 +158,7 @@
     public static final  String HEADLES_OPTION="-headless";
 
     /**
-     * we would like to have an singleton instance asap
+     * we would like to have an singleton instance ASAP
      */
     public ServerAccess() {
 
@@ -171,7 +169,7 @@
 
     /**
      *
-     * @return cahed instance. If none, then creates new
+     * @return cached instance. If none, then creates new
      */
     public static ServerLauncher getInstance() {
         if (server == null) {
@@ -183,7 +181,7 @@
     /**
      *
      * @return new not cached iserver instance on random port,
-     * usefull for testing application loading from different url then base
+     * useful for testing application loading from different url then base
      */
     public static ServerLauncher getIndependentInstance() {
         return getIndependentInstance(true);
@@ -201,7 +199,7 @@
     /**
      *
      * @return new not cached iserver instance on random port,
-     * usefull for testing application loading from different url then base
+     * useful for testing application loading from different url then base
      */
     
     public static ServerLauncher getIndependentInstance(int port) {
@@ -215,7 +213,7 @@
     /**
      *
      * @return new not cached iserver instance on random port upon custom www root directory,
-     * usefull for testing application loading from different url then base
+     * useful for testing application loading from different url then base
      */
 
     public static ServerLauncher getIndependentInstance(String dir, int port) {
@@ -382,7 +380,7 @@
 
     /**
      *
-     * @return port on which is runing cached server. If non singleton instance is runnig, new is created.
+     * @return port on which is running cached server. If non singleton instance is running, new is created.
      */
     public int getPort() {
         if (server == null) {
@@ -395,7 +393,7 @@
 
     /**
      *
-     * @return directory upon which is runing cached server. If non singleton instance is runnig, new is created.
+     * @return directory upon which is running cached server. If non singleton instance is running, new is created.
      */
     public File getDir() {
         if (server == null) {
@@ -407,7 +405,7 @@
 
     /**
      *
-     * @return url pointing to cached server resource. If non singleton instance is runnig, new is created.
+     * @return url pointing to cached server resource. If non singleton instance is running, new is created.
      */
     public URL getUrl(String resource) throws MalformedURLException {
         if (server == null) {
@@ -419,7 +417,7 @@
 
     /**
      *
-     * @return url pointing to cached server . If non singleton instance is runnig, new is created.
+     * @return url pointing to cached server . If non singleton instance is running, new is created.
      */
     public URL getUrl() throws MalformedURLException {
         return getUrl("");
@@ -428,7 +426,7 @@
 
     /**
      *
-     * @return weather cached server is alive. If non singleton instance is runnig, new is created.
+     * @return whether cached server is alive. If non singleton instance is running, new is created.
      */
     public boolean isRunning() {
         if (server == null) {
@@ -444,7 +442,7 @@
      * 
      * @param resource to be located on cached server
      * @return individual bytes of resource
-     * @throws IOException if connection cant be established or resource do not exists
+     * @throws IOException if connection can't be established or resource does not exist
      */
     public ByteArrayOutputStream getResourceAsBytes(String resource) throws IOException {
         return getResourceAsBytes(getUrl(resource));
@@ -455,7 +453,7 @@
      * 
      * @param resource to be located on cached server
      * @return string constructed from  resource
-     * @throws IOException if connection cant be established or resource do not exists
+     * @throws IOException if connection can't be established or resource does not exist
      */
     public String getResourceAsString(String resource) throws IOException {
         return getResourceAsString(getUrl(resource));
@@ -466,7 +464,7 @@
      * 
      * @param input stream to be read
      * @return individual bytes of resource
-     * @throws IOException if connection cant be established or resource do not exists
+     * @throws IOException if connection can't be established or resource does not exist
      */
     public static ByteArrayOutputStream getBytesFromStream(InputStream is) throws IOException {
         ByteArrayOutputStream buffer = new ByteArrayOutputStream();
@@ -484,7 +482,7 @@
      * 
      * @param input stream
      * @return stream as string
-     * @throws IOException if connection cant be established or resource do not exists
+     * @throws IOException if connection can't be established or resource does not exist
      */
     public static String getContentOfStream(InputStream is,String encoding) throws IOException {
         try {
@@ -510,7 +508,7 @@
      *
      * @param input stream
      * @return stream as string
-     * @throws IOException if connection cant be established or resource do not exists
+     * @throws IOException if connection can't be established or resource does not exist
      */
     public static String getContentOfStream(InputStream is) throws IOException {
         return getContentOfStream(is, "UTF-8");
@@ -522,7 +520,7 @@
      * 
      * @param resource to be located on any url
      * @return individual bytes of resource
-     * @throws IOException if connection cant be established or resource do not exists
+     * @throws IOException if connection can't be established or resource does not exist
      */
     public static ByteArrayOutputStream getResourceAsBytes(URL u) throws IOException {
         HttpURLConnection connection = (HttpURLConnection) u.openConnection();
@@ -538,9 +536,9 @@
     /**
      * utility method which can read string of resource from any url
      * 
-     * @param resource to be located onany url
+     * @param resource to be located on any url
      * @return resource as string
-     * @throws IOException if connection cant be established or resource do not exists
+     * @throws IOException if connection can't be established or resource does not exist
      */
     public static String getResourceAsString(URL u) throws IOException {
         HttpURLConnection connection = (HttpURLConnection) u.openConnection();
@@ -569,7 +567,7 @@
     /**
      * wrapping method to executeProcess (eg: javaws -headless http://localhost:port/resource)
      * will execute default javaws (@see JAVAWS_BUILD_BIN) upon default url upon cached server (@see SERVER_NAME @see getPort(), @see getInstance())
-     * with parameter -headles (no gui, no asking)
+     * with parameter -headless (no gui, no asking)
      * @param resource  name of resource
      * @return result what left after running this process
      * @throws Exception
@@ -584,9 +582,9 @@
     /**
      * wrapping method to executeProcess (eg: javaws arg arg -headless http://localhost:port/resource)
      * will execute default javaws (@see JAVAWS_BUILD_BIN) upon default url upon cached server (@see SERVER_NAME @see getPort(), @see getInstance())
-     * with parameter -headles (no gui, no asking)
+     * with parameter -headless (no gui, no asking)
      * @param resource  name of resource
-     * @param otherargs other arguments to be added to hedales one
+     * @param otherargs other arguments to be added to headless one
      * @return result what left after running this process
      * @throws Exception
      */
@@ -703,19 +701,19 @@
          return  executeProcess(args, null,stdoutl,stderrl);
      }
     /**
-     * utility method to lunch process, get its stdou/stderr, its return value and to kill it if runing to long (@see PROCESS_TIMEOUT)
+     * utility method to lunch process, get its stdout/stderr, its return value and to kill it if running to long (@see PROCESS_TIMEOUT)
      *
      *
      * Small bacground:
-     * This method creates thread inside which exec will be executed. Then creates assasin thread with given timeout to kill the previously created thread if necessary.
-     * Starts assasin thread, starts process thread. Wait untill process is running, then starts content readers.
+     * This method creates thread inside which exec will be executed. Then creates assassin thread with given timeout to kill the previously created thread if necessary.
+     * Starts assassin thread, starts process thread. Wait until process is running, then starts content readers.
      * Closes input of process.
-     * Wait until process is running (no metter if it teminate itself (correctly or badly), or is terminated by its assasin.
-     * Construct result from readed stdout, stderr, process return value, assasin sucessfulity
+     * Wait until process is running (no matter if it terminate itself (correctly or badly), or is terminated by its assassin.
+     * Construct result from readed stdout, stderr, process return value, assassin successfully
      *
      * @param args binary with args to be executed
      * @param dir optional, directory where this process will run
-     * @return what left from process - proces sitself, its stdout, stderr and return value and weather it was terminated by assasin.
+     * @return what left from process - process itself, its stdout, stderr and return value and whether it was terminated by assassin.
      * @throws Exception
      */
     public static ProcessResult executeProcess(final List<String> args,File dir) throws Exception {
@@ -760,8 +758,8 @@
 
     /**
      *
-     * wrapper arround Runtime.getRuntime().exec(...) which ensures taht process is run inside its own, by us controlled, thread.
-     * Proces sbuilder caused som einexpected and wired behaviour:/
+     * wrapper around Runtime.getRuntime().exec(...) which ensures that process is run inside its own, by us controlled, thread.
+     * Process builder caused some unexpected and weird behavior :/
      */
     private static class ThreadedProcess extends Thread {
 
@@ -834,17 +832,17 @@
                 }
                 try {
                     exitCode = p.waitFor();
-                    Thread.sleep(500);//this is giving to fastly done proecesses's e/o readers time to read all. I would like to know better solution :-/
+                    Thread.sleep(500); //this is giving to fast done proecesses's e/o readers time to read all. I would like to know better solution :-/
                 } finally {
                     destoyed = true;
                 }
             } catch (Exception ex) {
                 if (ex instanceof InterruptedException) {
-                    //add to the set of terminated threadedproceses
+                    //add to the set of terminated threaded processes
                     deadlyException = ex;
                     terminated.add(this);
                 } else {
-                    //happens when nonexisting process is launched, is causing p null!
+                    //happens when non-existing process is launched, is causing p null!
                     terminated.add(this);
                     deadlyException = ex;
                     throw new RuntimeException(ex);
@@ -856,8 +854,8 @@
     }
 
     /**
-     * wrapper arround tiny http server to separate lunch configgurations and servers.
-     * to allow terminations and stuff arround.
+     * wrapper around tiny http server to separate lunch configurations and servers.
+     * to allow terminations and stuff around.
      */
     public static class ServerLauncher implements Runnable {
 
@@ -1116,7 +1114,7 @@
 
 
     /**
-     * class which timeout any ThreadedProcess. This killing of 'theread with process' replaced not working process.destroy().
+     * class which timeout any ThreadedProcess. This killing of 'thread with process' replaced not working process.destroy().
      */
     private static class ProcessAssasin extends Thread {
 
@@ -1136,7 +1134,7 @@
         /**
          *
          * @param p
-         * @param timeout - time to die in milis
+         * @param timeout - time to die in milliseconds
          */
         public ProcessAssasin(ThreadedProcess p, long timeout) {
             this.p = (p);
@@ -1285,7 +1283,7 @@
     }
 
     /**
-     * Class to read content of stdou/err of process, and to cooperate with its running/terminated/finished statuses.
+     * Class to read content of stdout/stderr of process, and to cooperate with its running/terminated/finished statuses.
      */
     private static class ContentReader implements Runnable {
 


From bugzilla-daemon at icedtea.classpath.org  Fri Apr 20 09:32:50 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Fri, 20 Apr 2012 16:32:50 +0000
Subject: [Bug 797] Compiler error message does not display entire file name
	and path
In-Reply-To: <bug-797-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-797-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-797-30-95ev0DpnGW@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=797

Matthias Klose <doko at ubuntu.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #3 from Matthias Klose <doko at ubuntu.com> 2012-04-20 16:32:50 UTC ---
fixed, and the issue number mentioned in NEWS.

-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


From thomas at m3y3r.de  Sat Apr 21 01:17:26 2012
From: thomas at m3y3r.de (Thomas Meyer)
Date: Sat, 21 Apr 2012 10:17:26 +0200
Subject: [RFC] [openjdk] provide milisecond modification timestamps
Message-ID: <1334996246.1435.18.camel@localhost.localdomain>

diff -r 8ac52c85f9e9 src/solaris/native/java/io/UnixFileSystem_md.c
--- a/src/solaris/native/java/io/UnixFileSystem_md.c	Wed Feb 23 15:49:19
2011 -0800
+++ b/src/solaris/native/java/io/UnixFileSystem_md.c	Sat Apr 21 10:11:26
2012 +0200
@@ -197,7 +197,10 @@
     WITH_FIELD_PLATFORM_STRING(env, file, ids.path, path) {
         struct stat64 sb;
         if (stat64(path, &sb) == 0) {
-            rv = 1000 * (jlong)sb.st_mtime;
+            if(sb.st_mtimensec != 0)
+            	rv = (jlong)sb.st_mtimensec / 1000000;
+            else
+                rv = 1000 * (jlong)sb.st_mtime;
         }
     } END_PLATFORM_STRING(env, path);
     return rv;




From bugzilla-daemon at icedtea.classpath.org  Sat Apr 21 18:26:39 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Sun, 22 Apr 2012 01:26:39 +0000
Subject: [Bug 912] Pentaho Kettle' spoon.sh  fatal error, SIGSEGV
In-Reply-To: <bug-912-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-912-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-912-30-hHrlEUwCE9@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=912

--- Comment #2 from JJ <jjantmba at yahoo.es> 2012-04-22 01:26:39 UTC ---
Solved by replacing JVM. Everything is OK on Sun JVM.

-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


From dj at lucasit.com  Sun Apr 22 13:54:28 2012
From: dj at lucasit.com (DJ Lucas)
Date: Sun, 22 Apr 2012 15:54:28 -0500
Subject: Test suite failures
Message-ID: <4F947004.8080707@lucasit.com>

Guys and gals, I know there used to be a page on icedtea.classpath.org 
with recent test suite results, but I have been unable to find it. I've 
found the buildbot results, but no logs on jtreg. With my first build of 
2.1 (yes I'm running way behind) I had ~60 test failures before I killed 
it on x86_64.  Probably safe to say that those results were self 
inflicted, but I would like to do a comparison once I do get up to par 
(mind you this is very near a bleeding edge build). Do these posted 
results still exist? Pointers?

Thanks in advance.

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.



From mark at klomp.org  Sun Apr 22 13:51:55 2012
From: mark at klomp.org (Mark Wielaard)
Date: Sun, 22 Apr 2012 22:51:55 +0200
Subject: Bugzilla updates through mercurial commits
Message-ID: <20120422205154.GA2813@toonder.wildebeest.org>

Hi,

Mercurial was updated to 2.1.2 and Bugzilla was updated to 4.2.1 on
icedtea.classpath.org. The bugzilla xmlrpc interface has been enabled
and that is now used with a new incoming.bugzilla hook to let mercurial
update any bug mentioned in a commit message.

Hopefully the result is useful. If not we can of course tweak the config.

The following config is now used in hgrc on the server:

[extensions]
hgext.bugzilla =

[hooks]
# run bugzilla hook on every change pulled or pushed in here
incoming.bugzilla = python:hgext.bugzilla.hook

[bugzilla]
version=xmlrpc
# Catch things like PR icedtea/42, PR16, PR 16 or bug #11
regexp=(?:PR [a-z]+/|PR ?|bug ?)#?(\d+)
hgweb=http://icedtea.classpath.org/hg
template=details: {hgweb}/{webroot}?cmd=changeset;node={node|short}\nauthor: {author}\ndate: {date|date}\n\n\t{desc|tabindent|strip}
bzurl=http://icedtea.classpath.org/bugzilla

Cheers,

Mark


From mark at klomp.org  Mon Apr 23 00:35:53 2012
From: mark at klomp.org (Mark Wielaard)
Date: Mon, 23 Apr 2012 09:35:53 +0200
Subject: Bugzilla updates through mercurial commits
In-Reply-To: <1335165040.21255.4.camel@mercury.localdomain>
References: <20120422205154.GA2813@toonder.wildebeest.org>
	<1335165040.21255.4.camel@mercury.localdomain>
Message-ID: <20120423073553.GA17818@toonder.wildebeest.org>

On Mon, Apr 23, 2012 at 09:10:40AM +0200, Roman Kennke wrote:
> Hi Mark,
> 
> > # Catch things like PR icedtea/42, PR16, PR 16 or bug #11
> > regexp=(?:PR [a-z]+/|PR ?|bug ?)#?(\d+)
> [...]
> That's very cool!
> 
> What is the pattern in the commit message that triggers the hook?

The regexp above :)

Cheers,

Mark


From rkennke at redhat.com  Mon Apr 23 00:10:40 2012
From: rkennke at redhat.com (Roman Kennke)
Date: Mon, 23 Apr 2012 09:10:40 +0200
Subject: Bugzilla updates through mercurial commits
In-Reply-To: <20120422205154.GA2813@toonder.wildebeest.org>
References: <20120422205154.GA2813@toonder.wildebeest.org>
Message-ID: <1335165040.21255.4.camel@mercury.localdomain>

Hi Mark,

> Mercurial was updated to 2.1.2 and Bugzilla was updated to 4.2.1 on
> icedtea.classpath.org. The bugzilla xmlrpc interface has been enabled
> and that is now used with a new incoming.bugzilla hook to let mercurial
> update any bug mentioned in a commit message.
> 
> Hopefully the result is useful. If not we can of course tweak the config.
> 
> The following config is now used in hgrc on the server:
> 
> [extensions]
> hgext.bugzilla =
> 
> [hooks]
> # run bugzilla hook on every change pulled or pushed in here
> incoming.bugzilla = python:hgext.bugzilla.hook
> 
> [bugzilla]
> version=xmlrpc
> # Catch things like PR icedtea/42, PR16, PR 16 or bug #11
> regexp=(?:PR [a-z]+/|PR ?|bug ?)#?(\d+)
> hgweb=http://icedtea.classpath.org/hg
> template=details: {hgweb}/{webroot}?cmd=changeset;node={node|short}\nauthor: {author}\ndate: {date|date}\n\n\t{desc|tabindent|strip}
> bzurl=http://icedtea.classpath.org/bugzilla

That's very cool!

What is the pattern in the commit message that triggers the hook?

Cheers,
Roman




From jvanek at redhat.com  Mon Apr 23 03:02:59 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Mon, 23 Apr 2012 12:02:59 +0200
Subject: [icedtea-web] Broken unit-tests
Message-ID: <4F9528D3.5010801@redhat.com>

Hi!
After commit http://icedtea.classpath.org/hg/icedtea-web/rev/f13777a89e0d  the unittests xml result 
file generation is  broken. It is caused by:
....
Passed: net.sourceforge.jnlp.ParserCornerCases.testNestedComments
Passed: net.sourceforge.jnlp.ParserCornerCases.testDoubleDashesInComments
FAILED: testApplicationImages(net.sourceforge.jnlp.util.ImageResourcesTest) null
FAILED: Test mechanism null

Null tests mechanism exception is not properly catch and so the xml file is left unflushed and 
unclosed.  It is known issue for me and I have fixed it as part of 
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120320/8ef6bdfe/browserTests-BugAnnotation-0001.diff
which is next in line after make links.

If there is nothing against I will let it broken until this feature is going in.

J.



From omajid at redhat.com  Mon Apr 23 05:44:55 2012
From: omajid at redhat.com (Omair Majid)
Date: Mon, 23 Apr 2012 08:44:55 -0400
Subject: [icedtea-web] Broken unit-tests
In-Reply-To: <4F9528D3.5010801@redhat.com>
References: <4F9528D3.5010801@redhat.com>
Message-ID: <4F954EC7.5070107@redhat.com>

On 04/23/2012 06:02 AM, Jiri Vanek wrote:
> Hi!
> After commit
> http://icedtea.classpath.org/hg/icedtea-web/rev/f13777a89e0d  the
> unittests xml result file generation is  broken. It is caused by:
> ....
> Passed: net.sourceforge.jnlp.ParserCornerCases.testNestedComments
> Passed: net.sourceforge.jnlp.ParserCornerCases.testDoubleDashesInComments
> FAILED:
> testApplicationImages(net.sourceforge.jnlp.util.ImageResourcesTest) null
> FAILED: Test mechanism null

Would you mind if I went ahead and pushed this patch?

http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-March/017754.html

It fixes the test and thus makes 'make check' work again.

Thanks,
Omair


From jvanek at redhat.com  Mon Apr 23 06:26:19 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Mon, 23 Apr 2012 15:26:19 +0200
Subject: [icedtea-web] Broken unit-tests
In-Reply-To: <4F954EC7.5070107@redhat.com>
References: <4F9528D3.5010801@redhat.com> <4F954EC7.5070107@redhat.com>
Message-ID: <4F95587B.2030600@redhat.com>

On 04/23/2012 02:44 PM, Omair Majid wrote:
> On 04/23/2012 06:02 AM, Jiri Vanek wrote:
>> Hi!
>> After commit
>> http://icedtea.classpath.org/hg/icedtea-web/rev/f13777a89e0d  the
>> unittests xml result file generation is  broken. It is caused by:
>> ....
>> Passed: net.sourceforge.jnlp.ParserCornerCases.testNestedComments
>> Passed: net.sourceforge.jnlp.ParserCornerCases.testDoubleDashesInComments
>> FAILED:
>> testApplicationImages(net.sourceforge.jnlp.util.ImageResourcesTest) null
>> FAILED: Test mechanism null
>
> Would you mind if I went ahead and pushed this patch?
>
> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-March/017754.html
>
> It fixes the test and thus makes 'make check' work again.

I does??? It looks to me like completely  different issue :)
But the patch should not do any harm, unless :

In time we have been discussing this "awt robot" issue, you have suggested also to "get rid of 
misused xbootclasspath". Isn't that better then add resources.jar?


If you will play with xboothclassapth, please run reproducers test, they can catch a lot:)

J.

btw - The make check is not broken completely - only xml report (and so html report) are not 
generated properly.

>
> Thanks,
> Omair



From omajid at redhat.com  Mon Apr 23 06:33:52 2012
From: omajid at redhat.com (Omair Majid)
Date: Mon, 23 Apr 2012 09:33:52 -0400
Subject: [icedtea-web] Broken unit-tests
In-Reply-To: <4F95587B.2030600@redhat.com>
References: <4F9528D3.5010801@redhat.com> <4F954EC7.5070107@redhat.com>
	<4F95587B.2030600@redhat.com>
Message-ID: <4F955A40.90603@redhat.com>

On 04/23/2012 09:26 AM, Jiri Vanek wrote:
> On 04/23/2012 02:44 PM, Omair Majid wrote:
>> On 04/23/2012 06:02 AM, Jiri Vanek wrote:
>>> Hi!
>>> After commit
>>> http://icedtea.classpath.org/hg/icedtea-web/rev/f13777a89e0d  the
>>> unittests xml result file generation is  broken. It is caused by:
>>> ....
>>> Passed: net.sourceforge.jnlp.ParserCornerCases.testNestedComments
>>> Passed:
>>> net.sourceforge.jnlp.ParserCornerCases.testDoubleDashesInComments
>>> FAILED:
>>> testApplicationImages(net.sourceforge.jnlp.util.ImageResourcesTest) null
>>> FAILED: Test mechanism null
>>
>> Would you mind if I went ahead and pushed this patch?
>>
>> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-March/017754.html
>>
>>
>> It fixes the test and thus makes 'make check' work again.
> 
> I does??? It looks to me like completely  different issue :)

Well, something output by that the failing test produces makes the test
runner unhappy (I guess that's what your patch fixes?). The patch I
linked to makes the test pass (which removes that output and makes the
test runner happy).

> But the patch should not do any harm, unless :
> 
> In time we have been discussing this "awt robot" issue, you have
> suggested also to "get rid of misused xbootclasspath". Isn't that better
> then add resources.jar?
> 

Probably. But, unfortunately, I don't have time to work on this at the
moment and I suspect it's not quite simple (there are places in
netx/plugin that make the assumption that the code is part of the
bootclasspath (and loaded by the system classloader)).

Cheers,
Omair


From jvanek at redhat.com  Mon Apr 23 07:02:38 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Mon, 23 Apr 2012 16:02:38 +0200
Subject: [icedtea-web] Broken unit-tests
In-Reply-To: <4F955A40.90603@redhat.com>
References: <4F9528D3.5010801@redhat.com> <4F954EC7.5070107@redhat.com>
	<4F95587B.2030600@redhat.com> <4F955A40.90603@redhat.com>
Message-ID: <4F9560FE.5050905@redhat.com>

On 04/23/2012 03:33 PM, Omair Majid wrote:
> On 04/23/2012 09:26 AM, Jiri Vanek wrote:
>> On 04/23/2012 02:44 PM, Omair Majid wrote:
>>> On 04/23/2012 06:02 AM, Jiri Vanek wrote:
>>>> Hi!
>>>> After commit
>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/f13777a89e0d  the
>>>> unittests xml result file generation is  broken. It is caused by:
>>>> ....
>>>> Passed: net.sourceforge.jnlp.ParserCornerCases.testNestedComments
>>>> Passed:
>>>> net.sourceforge.jnlp.ParserCornerCases.testDoubleDashesInComments
>>>> FAILED:
>>>> testApplicationImages(net.sourceforge.jnlp.util.ImageResourcesTest) null
>>>> FAILED: Test mechanism null
>>>
>>> Would you mind if I went ahead and pushed this patch?
>>>
>>> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-March/017754.html
>>>
>>>
>>> It fixes the test and thus makes 'make check' work again.
>>
>> I does??? It looks to me like completely  different issue :)
>
> Well, something output by that the failing test produces makes the test
> runner unhappy (I guess that's what your patch fixes?). The patch I
> linked to makes the test pass (which removes that output and makes the
> test runner happy).
>
>> But the patch should not do any harm, unless :
>>
>> In time we have been discussing this "awt robot" issue, you have
>> suggested also to "get rid of misused xbootclasspath". Isn't that better
>> then add resources.jar?
>>
>
> Probably. But, unfortunately, I don't have time to work on this at the
I believe :(
> moment and I suspect it's not quite simple (there are places in
> netx/plugin that make the assumption that the code is part of the
> bootclasspath (and loaded by the system classloader)).
>
> Cheers,
> Omair

I really do not see an connection between your changeset,  the failure and the fix you are suggesting.

If you have tried and it is working for you, I think you can push. As it can be useful to have 
resources.jar on classapth anyway.

However - to fix this issue is better to  catch the proper exception in XmlOutputLIstener (which is 
probably consumed somehow and is causing the class lock itself in error state).


Thanx for keeping your eye on icedtea-web;)

J.



From jvanek at redhat.com  Mon Apr 23 08:46:56 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Mon, 23 Apr 2012 17:46:56 +0200
Subject: [rfc] [icedtea-web] make links
In-Reply-To: <7b067127-4d8c-4719-b390-da84e1e191bf@zmail17.collab.prod.int.phx2.redhat.com>
References: <7b067127-4d8c-4719-b390-da84e1e191bf@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <4F957970.2000100@redhat.com>

On 04/19/2012 08:54 PM, Andrew Hughes wrote:
>
>
> ----- Original Message -----
>> can I dare to ping? :)
>>
>> -------- Original Message --------
>> Subject: [rfc] [icedtea-web] make links
>> Date: Fri, 06 Apr 2012 16:55:04 +0200
>> From: Jiri Vanek<jvanek at redhat.com>
>> To: IcedTea Distro List<distro-pkg-dev at openjdk.java.net>
>>
>> Hi!
>>
>> This is third from total of 5 patches which are introducing Tets For
>> Applets[1]
>>
>> This particular one is introducing  detection of browsers, linking
>> the newly compiled plugin to
>> detected ones and forwarding this information to testengine..
>>
>> I know this linking by makefile is controversial, but it gives sense
>> to me.
>> Yes  - I can link the plugin with browsers manually before tests' run
>> (and yes, this can be done
>> once for all the runs in future), but I think this is much more
>> versatile and is much more
>> straightforward and much better controllable and also more
>> fool-proof. The question weather to
>> *UNlink* is more accurate:) ( there is no unlink right now, but
>> should be easily addable if requested.
>> Also when tests are run from makefile, then also all the possible
>> preparation should be done from
>> makefile. And this step is necessary. I have also introduced test
>> weather linking is correct see
>> private void testBrowser(Browser browser) calls in [2]
>>
>
> There are two main problems I see:
>
> 1.  You're calling global-links from the main run-netx-dist-tests
> target.  This means it'll get called by make check
No no, make check and make run-netx-dist-tests are independent targets
>.  So you're now
> requiring that test runs need root privileges and alter the installed
> plugin without reverting it. I don't think this is acceptable.
Yes... my idea was to run separate sudo make links and then make run-netx-dist-tests, and die quikly
> I have no problem with the targets being present, but they should be
> called manually.
Now they are.  Issu eis, that there isno way (except documentation) tah tests-runner should call 
them before run-netx-dist-tests (and when he does not, then probably the link will lead to old, 
installed version instead to freshly built one.

I have (in next changeset) tests to this behaviour, but it can take time for somebody inexpirienced 
to find the issue.

>
> 2.  You don't provide a way of reverting to the original status quo.
> I'd suggest:
>
> 	    mv -v ${HOME}/.mozilla/plugins/libjavaplugin.so ${HOME}/.mozilla/plugins/libjavaplugin.original.so&&  \
> 	    ln -s $(DESTDIR)$(libdir)/IcedTeaPlugin.so libjavaplugin.so&&  \
>
> and adding the inverse to revert back to the original setup after testing.
>
>              if [ -e ${HOME}/.mozilla/plugins/libjavaplugin.original.so ] ; \
>                 rm -f ${HOME}/.mozilla/plugins/libjavaplugin.so&&  \
>                 mv ${HOME}/.mozilla/plugins/libjavaplugin.original.so ${HOME}/.mozilla/plugins/libjavaplugin.so ; \
>              fi ;

I have added those targets.
I have copied the the backup to home, because browsers have been confused with duplicate entries 
(especially to two links pointing two different versions of same plugin ;)
>
> Other issues:
>
> 1.  Why is user-links never called from anywhere?  This is actually less
> dangerous (doesn't require root) and could be automated.
Yes. I want to test both linking. One of them had to  be called manually.  Now both of them have to be.
I'm not sure how to handle those linkage dependences and warnings to tester.
> 2.  You don't check that ${HOME}/.mozilla/plugins exists.
It should exists if some mozilla like browser is installed. And I'm checking for installed browsers, 
so this shouyld be ok.
> 3.  I think using ${HOME} as above may be safer than relying on tilde expansion by the shell.
fixed!
> 4.  I don't think we need the messages.  They may have been useful for debugging but can now be removed.
I have removed the messages. But then I have extended it for "unlink"  targets and it become quite 
confusing. Soi I have added them back and now is clear what are those manual targets doing. I'm for 
to kept them inside (two levels of conditional branching CAN be confusing).
> 5.  The dependencies on the new targets seem excessive.  All you need is whatever dependency ensures
> the plugin has been installed.  You don't need e.g. javaws.desktop or docs.stamp because you don't use
> them.
fied
> 6.  On that note, surely it should use the plugin from the build directory as people tend to run "make check"
> before "make install"?
50% true, 50% not ;) (If I translated it correctly)

make check and make run-netx-dist-tests are independent targets. Make check should be run before 
make install and have no linking work. But make run-netx-dist-tests MUST have icedtea-wen installed 
and MUST be run after make install, and is using those new linking targets

It give sense to me. (?)
>
>> What I'm missing is When I have choose AC_CHECK_PROGS, then it does
>> not support --with-val :-/ Is
>> there any AC_CHECK_PROGS which allows to set with-val?
>> Becasue I will probably put rather
>> --with-firefox=/my/preconfiguired/firefox instead of let it use
>> my default one. Although Lynks is quite good alternative during tests
>> runtime :)
>> Also this can be maybe intorduced as new patch later.
>>
>
> You probably want to look at mirroring something like IT_FIND_JAVAH in IcedTea.

Yap. Looks close. I would like to have this as separate patch if you agree.
>
>> Best regards J.
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-March/017799.html
>> [2]
>> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120320/8ef6bdfe/browserTests-tests-0001.diff
>> (btw, this page is partially corrupted - there is html test, and
>> firefox is trying to translate it
>> as html page :-/.. so see source rather :-/)
>>
>>
>> changelog:
>> 2012-04-06  Jiri Vanek<jvanek at redhat.com>
>>
>> 	Added detection of installed browsers and added targets to create
>> 	symbolic links from install dir
>> to browsers' plugin directories. Primarily for testing purposes
>> 	*Makefile.am: (clean-local) optionally delets links' stamps
>> 	(stamps/user-links.stamp) with alias (links) - new target for
>> 	creating symlinks for all users. One
>> must be root to execute this target.
>> 	(stamps/global-links.stamp) with alias (user-links) - new target for
>> 	creating symlinks for logged
>> user only. Because opera is missing this feature, quite useless.
>> 	*configure.ac: added basic check whether and which browsers are
>> 	installed
>>
>>
>

changelog:
2012-04-23  Jiri Vanek<jvanek at redhat.com>

  	Added detection of installed browsers and added targets to create
  	symbolic links from install dir
  to browsers' plugin directories. Primarily for testing purposes
  	*Makefile.am: (clean-local) optionally delets links' stamps
  	(stamps/user-links.stamp) with alias (links) - new target for
  	creating symlinks for all users. One
  must be root to execute this target.
  	(stamps/global-links.stamp) with alias (user-links) - new target for
  	creating symlinks for logged
	(restore-global-links): target for restoring original global links. One must be root again
  user only. Because opera is missing this feature, quite useless.
	(restore-user-links): target for rfrstoring user's links
  	*configure.ac: added basic check whether and which browsers are
  	installed



Tahnx for review!
And best regards!
      J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: makeLinks2.diff
Type: text/x-patch
Size: 10643 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120423/e9d3a757/makeLinks2.diff 

From ahughes at redhat.com  Mon Apr 23 09:41:34 2012
From: ahughes at redhat.com (Andrew Hughes)
Date: Mon, 23 Apr 2012 12:41:34 -0400 (EDT)
Subject: [RFC] [openjdk] provide milisecond modification timestamps
In-Reply-To: <1334996246.1435.18.camel@localhost.localdomain>
Message-ID: <23b8e3d6-0ce8-4da0-a902-fc0ed8bba3bf@zmail17.collab.prod.int.phx2.redhat.com>

----- Original Message -----
> diff -r 8ac52c85f9e9 src/solaris/native/java/io/UnixFileSystem_md.c
> --- a/src/solaris/native/java/io/UnixFileSystem_md.c	Wed Feb 23
> 15:49:19
> 2011 -0800
> +++ b/src/solaris/native/java/io/UnixFileSystem_md.c	Sat Apr 21
> 10:11:26
> 2012 +0200
> @@ -197,7 +197,10 @@
>      WITH_FIELD_PLATFORM_STRING(env, file, ids.path, path) {
>          struct stat64 sb;
>          if (stat64(path, &sb) == 0) {
> -            rv = 1000 * (jlong)sb.st_mtime;
> +            if(sb.st_mtimensec != 0)
> +            	rv = (jlong)sb.st_mtimensec / 1000000;
> +            else
> +                rv = 1000 * (jlong)sb.st_mtime;
>          }
>      } END_PLATFORM_STRING(env, path);
>      return rv;
> 
> 
> 

This looks a sensible improvement to me.  I can add it to the IcedTea
repository.

Have you signed the Oracle Contributor Agreement (OCA) so it can also
be upstreamed to OpenJDK?

Thanks,
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From thomas at m3y3r.de  Mon Apr 23 10:53:15 2012
From: thomas at m3y3r.de (Thomas Meyer)
Date: Mon, 23 Apr 2012 19:53:15 +0200
Subject: [RFC] [openjdk] provide milisecond modification timestamps
In-Reply-To: <23b8e3d6-0ce8-4da0-a902-fc0ed8bba3bf@zmail17.collab.prod.int.phx2.redhat.com>
References: <23b8e3d6-0ce8-4da0-a902-fc0ed8bba3bf@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <1335203595.1435.46.camel@localhost.localdomain>

Am Montag, den 23.04.2012, 12:41 -0400 schrieb Andrew Hughes:
> ----- Original Message -----
> > diff -r 8ac52c85f9e9 src/solaris/native/java/io/UnixFileSystem_md.c
> > --- a/src/solaris/native/java/io/UnixFileSystem_md.c	Wed Feb 23
> > 15:49:19
> > 2011 -0800
> > +++ b/src/solaris/native/java/io/UnixFileSystem_md.c	Sat Apr 21
> > 10:11:26
> > 2012 +0200
> > @@ -197,7 +197,10 @@
> >      WITH_FIELD_PLATFORM_STRING(env, file, ids.path, path) {
> >          struct stat64 sb;
> >          if (stat64(path, &sb) == 0) {
> > -            rv = 1000 * (jlong)sb.st_mtime;
> > +            if(sb.st_mtimensec != 0)
> > +            	rv = (jlong)sb.st_mtimensec / 1000000;
> > +            else
> > +                rv = 1000 * (jlong)sb.st_mtime;
> >          }
> >      } END_PLATFORM_STRING(env, path);
> >      return rv;
> > 
> > 
> > 
> 

Hi Andrew,

> This looks a sensible improvement to me.  I can add it to the IcedTea
> repository.

But it only looks sensible :-) The correct patch against jdk7 is
attached!

I looks like the field st_mtim.tv_nsec is just an extension to the
second accuracy provided by st_mtim.tv_sec.

But I don't know if this compiles on Solaris, etc... But according to
the man page of stat() it should compile if compatible to POSIX.1-2008.

> 
> Have you signed the Oracle Contributor Agreement (OCA) so it can also
> be upstreamed to OpenJDK?

Not yet...

thomas


-------------- next part --------------
A non-text attachment was scrubbed...
Name: provide-millisecond-timestamp.patch
Type: text/x-patch
Size: 583 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120423/38fd1493/provide-millisecond-timestamp.patch 

From ahughes at redhat.com  Mon Apr 23 11:22:34 2012
From: ahughes at redhat.com (Andrew Hughes)
Date: Mon, 23 Apr 2012 14:22:34 -0400 (EDT)
Subject: [RFC] [openjdk] provide milisecond modification timestamps
In-Reply-To: <1335203595.1435.46.camel@localhost.localdomain>
Message-ID: <ed8b243e-0f71-4320-bc42-f483ee7f32b6@zmail17.collab.prod.int.phx2.redhat.com>

----- Original Message -----
> Am Montag, den 23.04.2012, 12:41 -0400 schrieb Andrew Hughes:
> > ----- Original Message -----
> > > diff -r 8ac52c85f9e9
> > > src/solaris/native/java/io/UnixFileSystem_md.c
> > > --- a/src/solaris/native/java/io/UnixFileSystem_md.c	Wed Feb 23
> > > 15:49:19
> > > 2011 -0800
> > > +++ b/src/solaris/native/java/io/UnixFileSystem_md.c	Sat Apr 21
> > > 10:11:26
> > > 2012 +0200
> > > @@ -197,7 +197,10 @@
> > >      WITH_FIELD_PLATFORM_STRING(env, file, ids.path, path) {
> > >          struct stat64 sb;
> > >          if (stat64(path, &sb) == 0) {
> > > -            rv = 1000 * (jlong)sb.st_mtime;
> > > +            if(sb.st_mtimensec != 0)
> > > +            	rv = (jlong)sb.st_mtimensec / 1000000;
> > > +            else
> > > +                rv = 1000 * (jlong)sb.st_mtime;
> > >          }
> > >      } END_PLATFORM_STRING(env, path);
> > >      return rv;
> > > 
> > > 
> > > 
> > 
> 
> Hi Andrew,
> 
> > This looks a sensible improvement to me.  I can add it to the
> > IcedTea
> > repository.
> 
> But it only looks sensible :-) The correct patch against jdk7 is
> attached!
> 
> I looks like the field st_mtim.tv_nsec is just an extension to the
> second accuracy provided by st_mtim.tv_sec.
> 

Ah right, yes this is the same way clock_gettime works, which we use
to implement System.nanoTime in GNU Classpath:

  result = (jlong) tp.tv_sec;
  result *= (jlong)1000000000L;
  result += (jlong)tp.tv_nsec;

The difference here is that the Java API means that most of the accuracy
gain is lost in the division.  I wonder if there is a case for a deeper
patch that allows nanosecond accuracy to be fully exposed?

> But I don't know if this compiles on Solaris, etc... But according to
> the man page of stat() it should compile if compatible to
> POSIX.1-2008.
> 
> > 
> > Have you signed the Oracle Contributor Agreement (OCA) so it can
> > also
> > be upstreamed to OpenJDK?
> 
> Not yet...
> 
> thomas
> 
> 
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From andrew at icedtea.classpath.org  Mon Apr 23 13:10:32 2012
From: andrew at icedtea.classpath.org (andrew at icedtea.classpath.org)
Date: Mon, 23 Apr 2012 20:10:32 +0000
Subject: /hg/icedtea7: Stop libraries being stripped in the OpenJDK build.
Message-ID: <hg.f427c1c7d29c.1335211832.2873452341184383833@icedtea.classpath.org>

changeset f427c1c7d29c in /hg/icedtea7
details: http://icedtea.classpath.org/hg/icedtea7?cmd=changeset;node=f427c1c7d29c
author: Andrew John Hughes <ahughes at redhat.com>
date: Mon Apr 23 21:10:12 2012 +0100

	Stop libraries being stripped in the OpenJDK build.

	2012-04-23  Andrew John Hughes  <ahughes at redhat.com>

		* Makefile.am:
		(HOTSPOT_CHANGESET): Bump to bring in
		ALT_STRIP_POLICY fix.
		(HOTSPOT_SHA256SUM): Likewise.
		(ICEDTEA_ENV): Set ALT_STRIP_POLICY to
		no_strip.


diffstat:

 ChangeLog   |  9 +++++++++
 Makefile.am |  7 ++++---
 2 files changed, 13 insertions(+), 3 deletions(-)

diffs (47 lines):

diff -r b43c8ac7586b -r f427c1c7d29c ChangeLog
--- a/ChangeLog	Thu Apr 12 18:36:20 2012 +0100
+++ b/ChangeLog	Mon Apr 23 21:10:12 2012 +0100
@@ -1,3 +1,12 @@
+2012-04-23  Andrew John Hughes  <ahughes at redhat.com>
+
+	* Makefile.am:
+	(HOTSPOT_CHANGESET): Bump to bring in
+	ALT_STRIP_POLICY fix.
+	(HOTSPOT_SHA256SUM): Likewise.
+	(ICEDTEA_ENV): Set ALT_STRIP_POLICY to
+	no_strip.
+
 2012-04-12  Andrew John Hughes  <ahughes at redhat.com>
 
 	* Makefile.am:
diff -r b43c8ac7586b -r f427c1c7d29c Makefile.am
--- a/Makefile.am	Thu Apr 12 18:36:20 2012 +0100
+++ b/Makefile.am	Mon Apr 23 21:10:12 2012 +0100
@@ -5,7 +5,7 @@
 COMBINED_VERSION = $(JDK_UPDATE_VERSION)-$(OPENJDK_VERSION)
 
 CORBA_CHANGESET = c628aeb3d72f
-HOTSPOT_CHANGESET = b1dfb460ee5c
+HOTSPOT_CHANGESET = 2967c7838b7a
 JAXP_CHANGESET = 9b7a2f21b8a8
 JAXWS_CHANGESET = 9ae185bd7ff2
 JDK_CHANGESET = 1aea8312412a
@@ -13,7 +13,7 @@
 OPENJDK_CHANGESET = 3a0fd3cc84a0
 
 CORBA_SHA256SUM = b176cf1fd8a461413ab822236753cf455210e97c11a8d4224929582607c212b4
-HOTSPOT_SHA256SUM = 43d83d5209a9f748e6650c792ca8ef8d9a90d6e3c53e461993c6bffb8c37e972
+HOTSPOT_SHA256SUM = ea07bbffa5ce566efa4f7955983315bee006b0e60f7eacb36d14710e5da61b58
 JAXP_SHA256SUM = 4d38e8a0fc0fcbe3ba8a56f9fc0960ecbf15cd4cef44b76fdc82418c008a33c3
 JAXWS_SHA256SUM = 60c6c62c851eafc15ff33e58aa625e6f58fd31f15328b121602a07891fc1d272
 JDK_SHA256SUM = 1d5f1b7a5d9f8be06105130aa1c0f1898e9b91fb8d968d7ccb21d2b365575802
@@ -430,7 +430,8 @@
 	BUILD_CPP="$(CXX)" \
 	USE_SYSTEM_CUPS="true" \
 	CUPS_LIBS="${CUPS_LIBS}" \
-	CUPS_CFLAGS="${CUPS_CFLAGS}"
+	CUPS_CFLAGS="${CUPS_CFLAGS}" \
+	ALT_STRIP_POLICY=no_strip
 
 if ENABLE_CACAO
 ICEDTEA_ENV += \


From ptisnovs at redhat.com  Tue Apr 24 02:50:06 2012
From: ptisnovs at redhat.com (Pavel Tisnovsky)
Date: Tue, 24 Apr 2012 11:50:06 +0200
Subject: Test suite failures
In-Reply-To: <4F947004.8080707@lucasit.com>
References: <4F947004.8080707@lucasit.com>
Message-ID: <4F96774E.7020502@redhat.com>

Hi Lucas,

I've made some scripts for generating JTreg results, need to find a free
time :-) to install them and run them on a public place.

Pavel

DJ Lucas wrote:
> Guys and gals, I know there used to be a page on icedtea.classpath.org
> with recent test suite results, but I have been unable to find it. I've
> found the buildbot results, but no logs on jtreg. With my first build of
> 2.1 (yes I'm running way behind) I had ~60 test failures before I killed
> it on x86_64.  Probably safe to say that those results were self
> inflicted, but I would like to do a comparison once I do get up to par
> (mind you this is very near a bleeding edge build). Do these posted
> results still exist? Pointers?
> 
> Thanks in advance.
> 
> -- DJ Lucas
> 
> 



From ptisnovs at icedtea.classpath.org  Tue Apr 24 04:45:49 2012
From: ptisnovs at icedtea.classpath.org (ptisnovs at icedtea.classpath.org)
Date: Tue, 24 Apr 2012 11:45:49 +0000
Subject: /hg/gfx-test: * src/org/gfxtest/testsuites/PrintTestBasic.java:
Message-ID: <hg.905b20725f80.1335267949.-6248649288953172555@icedtea.classpath.org>

changeset 905b20725f80 in /hg/gfx-test
details: http://icedtea.classpath.org/hg/gfx-test?cmd=changeset;node=905b20725f80
author: Pavel Tisnovsky <ptisnovs at redhat.com>
date: Tue Apr 24 13:48:25 2012 +0200

	* src/org/gfxtest/testsuites/PrintTestBasic.java:
	Added new printing tests to this test suite.


diffstat:

 ChangeLog                                      |   5 +
 src/org/gfxtest/testsuites/PrintTestBasic.java |  97 +++++++++++++++++++++++++-
 2 files changed, 100 insertions(+), 2 deletions(-)

diffs (138 lines):

diff -r f72558a932b2 -r 905b20725f80 ChangeLog
--- a/ChangeLog	Fri Apr 20 15:22:51 2012 +0200
+++ b/ChangeLog	Tue Apr 24 13:48:25 2012 +0200
@@ -1,3 +1,8 @@
+2012-04-24  Pavel Tisnovsky  <ptisnovs at redhat.com>
+
+	* src/org/gfxtest/testsuites/PrintTestBasic.java:
+	Added new printing tests to this test suite.
+
 2012-04-20  Pavel Tisnovsky  <ptisnovs at redhat.com>
 
 	* src/org/gfxtest/framework/PrintingTest.java:
diff -r f72558a932b2 -r 905b20725f80 src/org/gfxtest/testsuites/PrintTestBasic.java
--- a/src/org/gfxtest/testsuites/PrintTestBasic.java	Fri Apr 20 15:22:51 2012 +0200
+++ b/src/org/gfxtest/testsuites/PrintTestBasic.java	Tue Apr 24 13:48:25 2012 +0200
@@ -73,6 +73,9 @@
 public class PrintTestBasic extends GfxTest
 {
 
+    private static final int HOR_STEP = 10;
+    private static final int VER_STEP = 10;
+
     /**
      * Test basic behavior of method Graphics.drawLine().
      *
@@ -82,13 +85,33 @@
      *            graphics canvas
      * @return test result status - PASSED, FAILED or ERROR
      */
-    public TestResult testDrawLine(TestImage image, Graphics2D graphics)
+    public TestResult testDrawDiagonalLine1(TestImage image, Graphics2D graphics)
+    {
+        // set drawing color
+        graphics.setColor(Color.BLACK);
+
+        // draw one diagonal line
+        graphics.drawLine(0, 0, image.getWidth(), image.getHeight());
+
+        // test return value
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Test basic behavior of method Graphics.drawLine().
+     *
+     * @param image
+     *            image to which line is to be drawn
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testDrawDiagonalLine2(TestImage image, Graphics2D graphics)
     {
         // set drawing color
         graphics.setColor(Color.BLACK);
 
         // draw two diagonals along the whole test image
-        graphics.drawLine(0, 0, image.getWidth(), image.getHeight());
         graphics.drawLine(0, image.getHeight(), image.getWidth(), 0);
 
         // test return value
@@ -96,6 +119,76 @@
     }
 
     /**
+     * Test basic behavior of method Graphics.drawLine().
+     *
+     * @param image
+     *            image to which line is to be drawn
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testDrawHorizontalLines(TestImage image, Graphics2D graphics)
+    {
+        // set drawing color
+        graphics.setColor(Color.BLACK);
+
+        // image width and height
+        int width = image.getWidth();
+        int height = image.getHeight();
+
+        // horizontal coordinates of line endpoints
+        int x1 = 0;
+        int x2 = width;
+
+        // draw all lines onto a paper
+        for (int y = 0; y < height; y += VER_STEP)
+        {
+            graphics.drawLine(x1, y, x2, y);
+            // compute new horizontal coordinates of line endpoints
+            x1 = Math.min(width / 2 - 10, x1 + 5);
+            x2 = Math.max(width / 2 + 10, x2 - 5);
+        }
+
+        // test return value
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Test basic behavior of method Graphics.drawLine().
+     *
+     * @param image
+     *            image to which line is to be drawn
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testDrawVerticalLines(TestImage image, Graphics2D graphics)
+    {
+        // set drawing color
+        graphics.setColor(Color.BLACK);
+
+        // image width and height
+        int width = image.getWidth();
+        int height = image.getHeight();
+
+        // vertical coordinates of line endpoints
+        int y1 = 0;
+        int y2 = height;
+
+        // draw all lines onto a paper
+        for (int x = 0; x < width; x += HOR_STEP)
+        {
+            graphics.drawLine(x, y1, x, y2);
+            // compute new vertical coordinates of line endpoints
+            y1 = Math.min(height / 2 - 10, y1 + 5);
+            y2 = Math.max(height / 2 + 10, y2 - 5);
+        }
+
+        // test return value
+        return TestResult.PASSED;
+    }
+
+    /**
      * Entry point to the test suite.
      *
      * @param args not used in this case


From ahughes at redhat.com  Tue Apr 24 08:07:23 2012
From: ahughes at redhat.com (Andrew Hughes)
Date: Tue, 24 Apr 2012 11:07:23 -0400 (EDT)
Subject: [rfc] [icedtea-web] make links
In-Reply-To: <4F957970.2000100@redhat.com>
Message-ID: <c3e9ac21-83bf-4316-9e9b-b305ddc609dd@zmail17.collab.prod.int.phx2.redhat.com>

Comments on this patch:

1.  Why the changes to clean-local?  Was there a reason clean-bootstrap-directory
needed to be earlier?
2.  Is there a reason you're using MOZZILA_{GLOBAL,LOCAL}_BACKUP_FILE instead
of MOZILLA_{LOCAL,GLOBAL}_BACKUP_FILE?  Thought it was a typo at first.
3.  "donot exists" should be "doesn't exist"
4.  Why the change to netx-unit-tests-compile?  Like 1, they seem unrelated
to the rest of the patch.

More below.

> >
> > 2.  You don't provide a way of reverting to the original status
> > quo.
> > I'd suggest:
> >
> > 	    mv -v ${HOME}/.mozilla/plugins/libjavaplugin.so
> > 	    ${HOME}/.mozilla/plugins/libjavaplugin.original.so&&  \
> > 	    ln -s $(DESTDIR)$(libdir)/IcedTeaPlugin.so libjavaplugin.so&&
> > 	     \
> >
> > and adding the inverse to revert back to the original setup after
> > testing.
> >
> >              if [ -e
> >              ${HOME}/.mozilla/plugins/libjavaplugin.original.so ]
> >              ; \
> >                 rm -f ${HOME}/.mozilla/plugins/libjavaplugin.so&&
> >                  \
> >                 mv
> >                 ${HOME}/.mozilla/plugins/libjavaplugin.original.so
> >                 ${HOME}/.mozilla/plugins/libjavaplugin.so ; \
> >              fi ;
> 
> I have added those targets.
> I have copied the the backup to home, because browsers have been
> confused with duplicate entries
> (especially to two links pointing two different versions of same
> plugin ;)

Ok, you'd know better than me.  I don't have any plugins in my browser :-)

> >
> > Other issues:
> >
> > 1.  Why is user-links never called from anywhere?  This is actually
> > less
> > dangerous (doesn't require root) and could be automated.
> Yes. I want to test both linking. One of them had to  be called
> manually.  Now both of them have to be.
> I'm not sure how to handle those linkage dependences and warnings to
> tester.

I don't think the restore ones should depend on the creation ones.
It seems intuitive, but in my experience, it leads to problems in cleanup.
They test for existence anyway.

For the creation ones, you just need to make sure the plugin exists
where it's expected to.  I don't think the current targets will do this
as they just create it in the build directory.

> > 2.  You don't check that ${HOME}/.mozilla/plugins exists.
> It should exists if some mozilla like browser is installed. And I'm
> checking for installed browsers,
> so this shouyld be ok.

Only if the browser has been run by the user before.

> > 3.  I think using ${HOME} as above may be safer than relying on
> > tilde expansion by the shell.
> fixed!

So I see.  I like the use of common variables too.

> > 4.  I don't think we need the messages.  They may have been useful
> > for debugging but can now be removed.
> I have removed the messages. But then I have extended it for "unlink"
>  targets and it become quite
> confusing. Soi I have added them back and now is clear what are those
> manual targets doing. I'm for
> to kept them inside (two levels of conditional branching CAN be
> confusing).

Looks a lot better.  Fine, other than the typo mentioned above.

> > 5.  The dependencies on the new targets seem excessive.  All you
> > need is whatever dependency ensures
> > the plugin has been installed.  You don't need e.g. javaws.desktop
> > or docs.stamp because you don't use
> > them.
> fied

Point 6...

> > 6.  On that note, surely it should use the plugin from the build
> > directory as people tend to run "make check"
> > before "make install"?
> 50% true, 50% not ;) (If I translated it correctly)
> 
> make check and make run-netx-dist-tests are independent targets. Make
> check should be run before
> make install and have no linking work. But make run-netx-dist-tests
> MUST have icedtea-wen installed
> and MUST be run after make install, and is using those new linking
> targets
> 
> It give sense to me. (?)

To me, I'd expect them to be part of make check as they're tests.
I wouldn't expect anything to run after make install.

A build I would expect to go:

1. configure
2. make
3. make check (optional)
4. make install

with 4 possibly being run by a different user at a completely different
time (e.g. a user builds it then an admin installs it for them to the system).
Or 4 could use DESTDIR to do a staged install.

The main issue is your dependencies only create a situation after stage 2.
It will break if you run make and then one of your test targets.

Why would you want to install it before testing it anyway?  I don't understand.
The user tests could be run as part of make check IMHO, though you may need to
use xvfb to run the browsers (as the jdk jtreg tests do).

> >
> >> What I'm missing is When I have choose AC_CHECK_PROGS, then it
> >> does
> >> not support --with-val :-/ Is
> >> there any AC_CHECK_PROGS which allows to set with-val?
> >> Becasue I will probably put rather
> >> --with-firefox=/my/preconfiguired/firefox instead of let it use
> >> my default one. Although Lynks is quite good alternative during
> >> tests
> >> runtime :)
> >> Also this can be maybe intorduced as new patch later.
> >>
> >
> > You probably want to look at mirroring something like IT_FIND_JAVAH
> > in IcedTea.
> 
> Yap. Looks close. I would like to have this as separate patch if you
> agree.

Yes, I would suggest the same thing.  Smaller patches focused on a single issue
are a lot easier to review :-)

> >
> >> Best regards J.
> >>
> >> [1]
> >> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-March/017799.html
> >> [2]
> >> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120320/8ef6bdfe/browserTests-tests-0001.diff
> >> (btw, this page is partially corrupted - there is html test, and
> >> firefox is trying to translate it
> >> as html page :-/.. so see source rather :-/)
> >>
> >>
> >> changelog:
> >> 2012-04-06  Jiri Vanek<jvanek at redhat.com>
> >>
> >> 	Added detection of installed browsers and added targets to create
> >> 	symbolic links from install dir
> >> to browsers' plugin directories. Primarily for testing purposes
> >> 	*Makefile.am: (clean-local) optionally delets links' stamps
> >> 	(stamps/user-links.stamp) with alias (links) - new target for
> >> 	creating symlinks for all users. One
> >> must be root to execute this target.
> >> 	(stamps/global-links.stamp) with alias (user-links) - new target
> >> 	for
> >> 	creating symlinks for logged
> >> user only. Because opera is missing this feature, quite useless.
> >> 	*configure.ac: added basic check whether and which browsers are
> >> 	installed
> >>
> >>
> >
> 
> changelog:
> 2012-04-23  Jiri Vanek<jvanek at redhat.com>
> 
>   	Added detection of installed browsers and added targets to create
>   	symbolic links from install dir
>   to browsers' plugin directories. Primarily for testing purposes
>   	*Makefile.am: (clean-local) optionally delets links' stamps
>   	(stamps/user-links.stamp) with alias (links) - new target for
>   	creating symlinks for all users. One
>   must be root to execute this target.
>   	(stamps/global-links.stamp) with alias (user-links) - new target
>   	for
>   	creating symlinks for logged
> 	(restore-global-links): target for restoring original global links.
> 	One must be root again
>   user only. Because opera is missing this feature, quite useless.
> 	(restore-user-links): target for rfrstoring user's links
>   	*configure.ac: added basic check whether and which browsers are
>   	installed
> 
> 
> 
> Tahnx for review!
> And best regards!
>       J.
> 

Thanks for doing this work,
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From omajid at redhat.com  Tue Apr 24 08:28:15 2012
From: omajid at redhat.com (Omair Majid)
Date: Tue, 24 Apr 2012 11:28:15 -0400
Subject: [icedtea-web] Broken unit-tests
In-Reply-To: <4F9560FE.5050905@redhat.com>
References: <4F9528D3.5010801@redhat.com> <4F954EC7.5070107@redhat.com>
	<4F95587B.2030600@redhat.com> <4F955A40.90603@redhat.com>
	<4F9560FE.5050905@redhat.com>
Message-ID: <4F96C68F.30101@redhat.com>

On 04/23/2012 10:02 AM, Jiri Vanek wrote:
> I really do not see an connection between your changeset,  the failure
> and the fix you are suggesting.

Well, you are probably aware that 'make check' was working before that
changeset was pushed to the repo, right?  So Something in that changeset
is breaking the test runner. So there are two way to fix it:

1. Fix the test so it doesn't break the test runner.

2. Fix the test runner so it can handle this problematic test.

Your patch (from what I can tell) takes approach 2. The fix for
resources.jar takes approach 1 (and makes the test pass).

It would be good to have fixes for both 1 _and_ 2, so that no future
test can break the runner and the current test passes.

> If you have tried and it is working for you, I think you can push. As it
> can be useful to have resources.jar on classapth anyway.

I will push it in a bit.

> However - to fix this issue is better to  catch the proper exception in
> XmlOutputLIstener (which is probably consumed somehow and is causing the
> class lock itself in error state).

Oh, yes. The test runner needs to be fixed too. If you want to post an
isolated patch for just this, I will try and review it.

Cheers,
Omair


From thomas at m3y3r.de  Tue Apr 24 10:28:50 2012
From: thomas at m3y3r.de (Thomas Meyer)
Date: Tue, 24 Apr 2012 19:28:50 +0200
Subject: [RFC] [openjdk] provide milisecond modification timestamps
In-Reply-To: <ed8b243e-0f71-4320-bc42-f483ee7f32b6@zmail17.collab.prod.int.phx2.redhat.com>
References: <ed8b243e-0f71-4320-bc42-f483ee7f32b6@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <1335288530.1393.9.camel@localhost.localdomain>

Am Montag, den 23.04.2012, 14:22 -0400 schrieb Andrew Hughes:
> ----- Original Message -----
> > Am Montag, den 23.04.2012, 12:41 -0400 schrieb Andrew Hughes:
> > > ----- Original Message -----
> > > > diff -r 8ac52c85f9e9
> > > > src/solaris/native/java/io/UnixFileSystem_md.c
> > > > --- a/src/solaris/native/java/io/UnixFileSystem_md.c	Wed Feb 23
> > > > 15:49:19
> > > > 2011 -0800
> > > > +++ b/src/solaris/native/java/io/UnixFileSystem_md.c	Sat Apr 21
> > > > 10:11:26
> > > > 2012 +0200
> > > > @@ -197,7 +197,10 @@
> > > >      WITH_FIELD_PLATFORM_STRING(env, file, ids.path, path) {
> > > >          struct stat64 sb;
> > > >          if (stat64(path, &sb) == 0) {
> > > > -            rv = 1000 * (jlong)sb.st_mtime;
> > > > +            if(sb.st_mtimensec != 0)
> > > > +            	rv = (jlong)sb.st_mtimensec / 1000000;
> > > > +            else
> > > > +                rv = 1000 * (jlong)sb.st_mtime;
> > > >          }
> > > >      } END_PLATFORM_STRING(env, path);
> > > >      return rv;
> > > > 
> > > > 
> > > > 
> > > 
> > 
> > Hi Andrew,
> > 
> > > This looks a sensible improvement to me.  I can add it to the
> > > IcedTea
> > > repository.
> > 
> > But it only looks sensible :-) The correct patch against jdk7 is
> > attached!
> > 
> > I looks like the field st_mtim.tv_nsec is just an extension to the
> > second accuracy provided by st_mtim.tv_sec.
> > 
> 
> Ah right, yes this is the same way clock_gettime works, which we use
> to implement System.nanoTime in GNU Classpath:
> 
>   result = (jlong) tp.tv_sec;
>   result *= (jlong)1000000000L;
>   result += (jlong)tp.tv_nsec;
> 
> The difference here is that the Java API means that most of the accuracy
> gain is lost in the division.  I wonder if there is a case for a deeper
> patch that allows nanosecond accuracy to be fully exposed?

At least not for File.lastModified() which returns "a long value
representing the time the file was last modified, measured in
milliseconds since the epoch".

[me having a quick look at the new stuff in 1.7]

Oh, nice! Java 7 seems to have FileTime and Files.getLastModifiedTime().

But I guess the 1.7 API is no option for icedtea-web (yet)?!

> 
> > But I don't know if this compiles on Solaris, etc... But according to
> > the man page of stat() it should compile if compatible to
> > POSIX.1-2008.
> > 
> > > 
> > > Have you signed the Oracle Contributor Agreement (OCA) so it can
> > > also
> > > be upstreamed to OpenJDK?
> > 
> > Not yet...
> > 
> > thomas
> > 
> > 
> > 
> 





From dbhole at redhat.com  Tue Apr 24 10:36:54 2012
From: dbhole at redhat.com (Deepak Bhole)
Date: Tue, 24 Apr 2012 13:36:54 -0400
Subject: [RFC] [openjdk] provide milisecond modification timestamps
In-Reply-To: <1335288530.1393.9.camel@localhost.localdomain>
References: <ed8b243e-0f71-4320-bc42-f483ee7f32b6@zmail17.collab.prod.int.phx2.redhat.com>
	<1335288530.1393.9.camel@localhost.localdomain>
Message-ID: <20120424173654.GG9568@redhat.com>

* Thomas Meyer <thomas at m3y3r.de> [2012-04-24 13:30]:
> Am Montag, den 23.04.2012, 14:22 -0400 schrieb Andrew Hughes:
> > ----- Original Message -----
> > > Am Montag, den 23.04.2012, 12:41 -0400 schrieb Andrew Hughes:
> > > > ----- Original Message -----
> > > > > diff -r 8ac52c85f9e9
> > > > > src/solaris/native/java/io/UnixFileSystem_md.c
> > > > > --- a/src/solaris/native/java/io/UnixFileSystem_md.c	Wed Feb 23
> > > > > 15:49:19
> > > > > 2011 -0800
> > > > > +++ b/src/solaris/native/java/io/UnixFileSystem_md.c	Sat Apr 21
> > > > > 10:11:26
> > > > > 2012 +0200
> > > > > @@ -197,7 +197,10 @@
> > > > >      WITH_FIELD_PLATFORM_STRING(env, file, ids.path, path) {
> > > > >          struct stat64 sb;
> > > > >          if (stat64(path, &sb) == 0) {
> > > > > -            rv = 1000 * (jlong)sb.st_mtime;
> > > > > +            if(sb.st_mtimensec != 0)
> > > > > +            	rv = (jlong)sb.st_mtimensec / 1000000;
> > > > > +            else
> > > > > +                rv = 1000 * (jlong)sb.st_mtime;
> > > > >          }
> > > > >      } END_PLATFORM_STRING(env, path);
> > > > >      return rv;
> > > > > 
> > > > > 
> > > > > 
> > > > 
> > > 
> > > Hi Andrew,
> > > 
> > > > This looks a sensible improvement to me.  I can add it to the
> > > > IcedTea
> > > > repository.
> > > 
> > > But it only looks sensible :-) The correct patch against jdk7 is
> > > attached!
> > > 
> > > I looks like the field st_mtim.tv_nsec is just an extension to the
> > > second accuracy provided by st_mtim.tv_sec.
> > > 
> > 
> > Ah right, yes this is the same way clock_gettime works, which we use
> > to implement System.nanoTime in GNU Classpath:
> > 
> >   result = (jlong) tp.tv_sec;
> >   result *= (jlong)1000000000L;
> >   result += (jlong)tp.tv_nsec;
> > 
> > The difference here is that the Java API means that most of the accuracy
> > gain is lost in the division.  I wonder if there is a case for a deeper
> > patch that allows nanosecond accuracy to be fully exposed?
> 
> At least not for File.lastModified() which returns "a long value
> representing the time the file was last modified, measured in
> milliseconds since the epoch".
> 
> [me having a quick look at the new stuff in 1.7]
> 
> Oh, nice! Java 7 seems to have FileTime and Files.getLastModifiedTime().
> 
> But I guess the 1.7 API is no option for icedtea-web (yet)?!
>

Right. At least until 6 EOL, I would like to hold off putting anything 7
specific -- and we will certainly have at least one more release cut
from HEAD before then.

Cheers,
Deepak
 
> > 
> > > But I don't know if this compiles on Solaris, etc... But according to
> > > the man page of stat() it should compile if compatible to
> > > POSIX.1-2008.
> > > 
> > > > 
> > > > Have you signed the Oracle Contributor Agreement (OCA) so it can
> > > > also
> > > > be upstreamed to OpenJDK?
> > > 
> > > Not yet...
> > > 
> > > thomas
> > > 
> > > 
> > > 
> > 
> 
> 
> 


From omajid at icedtea.classpath.org  Tue Apr 24 11:45:47 2012
From: omajid at icedtea.classpath.org (omajid at icedtea.classpath.org)
Date: Tue, 24 Apr 2012 18:45:47 +0000
Subject: /hg/icedtea-web: Add resources.jar to classpath
Message-ID: <hg.82e908d46d70.1335293147.8643924302249223276@icedtea.classpath.org>

changeset 82e908d46d70 in /hg/icedtea-web
details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=82e908d46d70
author: Omair Majid <omajid at redhat.com>
date: Tue Apr 24 14:43:34 2012 -0400

	Add resources.jar to classpath

	2012-04-24  Omair Majid  <omajid at redhat.com>

	       * Makefile.am
	       (RUNTIME): Add resources.jar.
	       (stamps/run-unit-test-code-coverage.stamp) [WITH_EMMA]: Add resouces.jar
	       to classpath.
	       (stamps/run-reproducers-test-code-coverage.stamp) [WITH_EMMA]: Include
	       resources.jar in classpath.
	       (stamps/bootstrap-directory.stamp): Create a link to resources.jar in
	       BOOT_DIR.


diffstat:

 ChangeLog   |  11 +++++++++++
 Makefile.am |   9 ++++++++-
 2 files changed, 19 insertions(+), 1 deletions(-)

diffs (58 lines):

diff -r a1c138829627 -r 82e908d46d70 ChangeLog
--- a/ChangeLog	Fri Apr 20 17:17:59 2012 +0200
+++ b/ChangeLog	Tue Apr 24 14:43:34 2012 -0400
@@ -1,3 +1,14 @@
+2012-04-24  Omair Majid  <omajid at redhat.com>
+
+	* Makefile.am
+	(RUNTIME): Add resources.jar.
+	(stamps/run-unit-test-code-coverage.stamp) [WITH_EMMA]: Add resouces.jar
+	to classpath.
+	(stamps/run-reproducers-test-code-coverage.stamp) [WITH_EMMA]: Include
+	resources.jar in classpath.
+	(stamps/bootstrap-directory.stamp): Create a link to resources.jar in
+	BOOT_DIR.
+
 2012-04-19  Omair Majid  <omajid at redhat.com>
 
 	PR918: java applet windows uses a low resulution black/white icon
diff -r a1c138829627 -r 82e908d46d70 Makefile.am
--- a/Makefile.am	Fri Apr 20 17:17:59 2012 +0200
+++ b/Makefile.am	Tue Apr 24 14:43:34 2012 -0400
@@ -45,7 +45,7 @@
   RHINO_RUNTIME=
 endif
 
-RUNTIME = $(BOOT_DIR)/jre/lib/rt.jar:$(BOOT_DIR)/jre/lib/jsse.jar$(RHINO_RUNTIME)
+RUNTIME = $(BOOT_DIR)/jre/lib/rt.jar:$(BOOT_DIR)/jre/lib/jsse.jar$(RHINO_RUNTIME):$(BOOT_DIR)/jre/lib/resources.jar
 
 # Flags
 IT_CFLAGS=$(CFLAGS) $(ARCHFLAG)
@@ -661,6 +661,7 @@
 	 -cp $(JUNIT_RUNNER_JAR) \
 	 -cp $(BOOT_DIR)/jre/lib/rt.jar \
 	 -cp $(BOOT_DIR)/jre/lib/jsse.jar \
+	 -cp $(BOOT_DIR)/jre/lib/resources.jar \
 	 -cp $(RHINO_RUNTIME) \
 	 -cp . \
 	 -ix "-org.junit.*" \
@@ -723,6 +724,7 @@
 	   -cp $(JUNIT_RUNNER_JAR) \
 	   -cp $(BOOT_DIR)/jre/lib/rt.jar \
 	   -cp $(BOOT_DIR)/jre/lib/jsse.jar \
+	   -cp $(BOOT_DIR)/jre/lib/resources.jar \
 	   -cp $(RHINO_RUNTIME) \
 	   -cp . \
 	   -ix "-org.junit.*" \
@@ -921,6 +923,11 @@
 	else \
 	  ln -s rt.jar $(BOOT_DIR)/jre/lib/jsse.jar ; \
 	fi
+	if [ -e $(SYSTEM_JRE_DIR)/lib/resources.jar ] ; then \
+	  ln -s $(SYSTEM_JRE_DIR)/lib/resources.jar $(BOOT_DIR)/jre/lib ; \
+	else \
+	  ln -s rt.jar $(BOOT_DIR)/jre/lib/resources.jar ; \
+	fi
 	ln -sf $(SYSTEM_JRE_DIR)/lib/$(JRE_ARCH_DIR) \
 	  $(BOOT_DIR)/jre/lib/ && \
 	if ! test -d $(BOOT_DIR)/jre/lib/$(INSTALL_ARCH_DIR); \


From omajid at redhat.com  Tue Apr 24 11:50:22 2012
From: omajid at redhat.com (Omair Majid)
Date: Tue, 24 Apr 2012 14:50:22 -0400
Subject: java.lang.InternalError - No RenderingEngine module found
In-Reply-To: <4F67457B.9010904@redhat.com>
References: <4F60BAFA.5060202@redhat.com> <4F60C341.7090602@redhat.com>
	<4F60C52C.2040500@redhat.com> <4F63CBB6.6040604@redhat.com>
	<4F67457B.9010904@redhat.com>
Message-ID: <4F96F5EE.1080503@redhat.com>

On 03/19/2012 10:40 AM, Jiri Vanek wrote:
> On 03/17/2012 12:24 AM, Omair Majid wrote:
>> Ok, I see the problem now. Implementations of RenderingEngine are stored
>> in rt.jar, but java uses the ServiceLoader mechanism to locate and use
>> an implementation of RenderingEngine. In this case, ServiceLoader looks
>> for META-INF/services/sun.java2d.pipe.RenderingEngine files in any jars
>> on the classpath to find the implementations of RenderingEngine. This
>> file, in icedtea (and openjdk), is stored in resources.jar which we do
>> not add to the classpath when building.
>>
>> The attached patch works for me. It runs the test (which fails).
> Wooou! Tyvm for wise advice!
> In case this will be needed, will it be possible to apply this patch for
> icedtea-web head? If no - then only for tests running?

As discussed in another thread, this is needed for tests that load
images too. I have pushed this fix to HEAD.

Cheers,
Omair


From ahughes at redhat.com  Tue Apr 24 17:23:00 2012
From: ahughes at redhat.com (Andrew Hughes)
Date: Tue, 24 Apr 2012 20:23:00 -0400 (EDT)
Subject: /hg/icedtea-web: Spelling fixes
In-Reply-To: <hg.a1c138829627.1334935216.8643924302249223276@icedtea.classpath.org>
Message-ID: <fa59594e-112b-4644-8b67-a18a794f1d88@zmail17.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> changeset a1c138829627 in /hg/icedtea-web
> details:
> http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=a1c138829627
> author: Thomas Meyer <thomas at m3y3r.de>
> date: Fri Apr 20 17:17:59 2012 +0200
> 
> 	Spelling fixes
> 
> 
> diffstat:
> 
>  tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java |
>   106 ++++-----
>  1 files changed, 52 insertions(+), 54 deletions(-)
> 

This change needs a ChangeLog entry.

Was it reviewed on the list?  I don't see a review, but may have missed it.
Given it's just typo corrections, it can probably go in as trivial.  But it
does need a ChangeLog.
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From ahughes at redhat.com  Tue Apr 24 17:39:16 2012
From: ahughes at redhat.com (Andrew Hughes)
Date: Tue, 24 Apr 2012 20:39:16 -0400 (EDT)
Subject: [RFC] [openjdk] provide milisecond modification timestamps
In-Reply-To: <1335288530.1393.9.camel@localhost.localdomain>
Message-ID: <21902c50-a21f-4605-b82c-3ed494fa1c9a@zmail17.collab.prod.int.phx2.redhat.com>

----- Original Message -----
> Am Montag, den 23.04.2012, 14:22 -0400 schrieb Andrew Hughes:
> > ----- Original Message -----
> > > Am Montag, den 23.04.2012, 12:41 -0400 schrieb Andrew Hughes:
> > > > ----- Original Message -----
> > > > > diff -r 8ac52c85f9e9
> > > > > src/solaris/native/java/io/UnixFileSystem_md.c
> > > > > --- a/src/solaris/native/java/io/UnixFileSystem_md.c	Wed Feb
> > > > > 23
> > > > > 15:49:19
> > > > > 2011 -0800
> > > > > +++ b/src/solaris/native/java/io/UnixFileSystem_md.c	Sat Apr
> > > > > 21
> > > > > 10:11:26
> > > > > 2012 +0200
> > > > > @@ -197,7 +197,10 @@
> > > > >      WITH_FIELD_PLATFORM_STRING(env, file, ids.path, path) {
> > > > >          struct stat64 sb;
> > > > >          if (stat64(path, &sb) == 0) {
> > > > > -            rv = 1000 * (jlong)sb.st_mtime;
> > > > > +            if(sb.st_mtimensec != 0)
> > > > > +            	rv = (jlong)sb.st_mtimensec / 1000000;
> > > > > +            else
> > > > > +                rv = 1000 * (jlong)sb.st_mtime;
> > > > >          }
> > > > >      } END_PLATFORM_STRING(env, path);
> > > > >      return rv;
> > > > > 
> > > > > 
> > > > > 
> > > > 
> > > 
> > > Hi Andrew,
> > > 
> > > > This looks a sensible improvement to me.  I can add it to the
> > > > IcedTea
> > > > repository.
> > > 
> > > But it only looks sensible :-) The correct patch against jdk7 is
> > > attached!
> > > 
> > > I looks like the field st_mtim.tv_nsec is just an extension to
> > > the
> > > second accuracy provided by st_mtim.tv_sec.
> > > 
> > 
> > Ah right, yes this is the same way clock_gettime works, which we
> > use
> > to implement System.nanoTime in GNU Classpath:
> > 
> >   result = (jlong) tp.tv_sec;
> >   result *= (jlong)1000000000L;
> >   result += (jlong)tp.tv_nsec;
> > 
> > The difference here is that the Java API means that most of the
> > accuracy
> > gain is lost in the division.  I wonder if there is a case for a
> > deeper
> > patch that allows nanosecond accuracy to be fully exposed?
> 
> At least not for File.lastModified() which returns "a long value
> representing the time the file was last modified, measured in
> milliseconds since the epoch".
> 

Yes, I guessed that.  But it doesn't mean another method couldn't be added.
But...

> [me having a quick look at the new stuff in 1.7]
> 
> Oh, nice! Java 7 seems to have FileTime and
> Files.getLastModifiedTime().
> 

...I'm guessing Oracle will just point to this new API.  Does it provide
nanosecond accuracy?

> But I guess the 1.7 API is no option for icedtea-web (yet)?!
> 

I don't see why IcedTea-Web is relevant to this discussion?

> > 
> > > But I don't know if this compiles on Solaris, etc... But
> > > according to
> > > the man page of stat() it should compile if compatible to
> > > POSIX.1-2008.
> > > 
> > > > 
> > > > Have you signed the Oracle Contributor Agreement (OCA) so it
> > > > can
> > > > also
> > > > be upstreamed to OpenJDK?
> > > 
> > > Not yet...
> > > 
> > > thomas
> > > 
> > > 
> > > 
> > 
> 
> 
> 
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From thomas at m3y3r.de  Wed Apr 25 00:47:46 2012
From: thomas at m3y3r.de (Thomas Meyer)
Date: Wed, 25 Apr 2012 09:47:46 +0200
Subject: /hg/icedtea-web: Spelling fixes
In-Reply-To: <fa59594e-112b-4644-8b67-a18a794f1d88@zmail17.collab.prod.int.phx2.redhat.com>
References: <fa59594e-112b-4644-8b67-a18a794f1d88@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <20120425094746.17236ey7mmvth1r6@webmail.your-server.de>


Zitat von Andrew Hughes <ahughes at redhat.com>:
> ----- Original Message -----
>> diffstat:
>>
>>  tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java |
>>   106 ++++-----
>>  1 files changed, 52 insertions(+), 54 deletions(-)
>>
>
> This change needs a ChangeLog entry.
>
> Was it reviewed on the list?

Yes, it was. Also somebody told me, that this kind of change doesn't  
need a review.

> I don't see a review, but may have missed it.
> Given it's just typo corrections, it can probably go in as trivial.  But it
> does need a ChangeLog.

Okay, I didn't know that. So every change needs a Changelog entry,  
sound sensible :-) Should I add an entry for this change to the  
Changelog?

PS: Why is the Changelog needed at all? The source code is under  
control of mercurial, so you have a changelog anyway?

with kind regards
thomas




From jvanek at redhat.com  Wed Apr 25 01:02:19 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Wed, 25 Apr 2012 10:02:19 +0200
Subject: [icedtea-web] Broken unit-tests
In-Reply-To: <4F96C68F.30101@redhat.com>
References: <4F9528D3.5010801@redhat.com> <4F954EC7.5070107@redhat.com>
	<4F95587B.2030600@redhat.com> <4F955A40.90603@redhat.com>
	<4F9560FE.5050905@redhat.com> <4F96C68F.30101@redhat.com>
Message-ID: <4F97AF8B.9010107@redhat.com>

On 04/24/2012 05:28 PM, Omair Majid wrote:
> On 04/23/2012 10:02 AM, Jiri Vanek wrote:
>> I really do not see an connection between your changeset,  the failure
>> and the fix you are suggesting.
>

I wrote it quite badly. My point was, that I was not sure why your changeset needed resources.jar. 
There was no  need for it as I read it.
However I analysed the stacktrace wrongly -  and so I have not seen the "deeper need" for resources.jar.

However patch is in and have solved the issue. And the folk saying "Omair is (nearly) always right" 
force me to dig what was so needed form resources.jar  in such s simple (and understandable) patch.
(any comment if you will have enough time will be appreciated O:)
 >
> Well, you are probably aware that 'make check' was working before that
> changeset was pushed to the repo, right?  So Something in that changeset
> is breaking the test runner. So there are two way to fix it:
>
> 1. Fix the test so it doesn't break the test runner.
>
> 2. Fix the test runner so it can handle this problematic test.
>
> Your patch (from what I can tell) takes approach 2. The fix for
> resources.jar takes approach 1 (and makes the test pass).

True :)

>
> It would be good to have fixes for both 1 _and_ 2, so that no future
> test can break the runner and the current test passes.
>
Sure:)

>> If you have tried and it is working for you, I think you can push. As it
>> can be useful to have resources.jar on classapth anyway.
>
> I will push it in a bit.

Thanx for pushing this!

>
>> However - to fix this issue is better to  catch the proper exception in
>> XmlOutputLIstener (which is probably consumed somehow and is causing the
>> class lock itself in error state).
>
> Oh, yes. The test runner needs to be fixed too. If you want to post an
> isolated patch for just this, I will try and review it.
>

The patch will not be as isolated as you wish, because I have already merged it with one more 
changeset (where I got into issue with test mechanism null). It was nothing else then one  null 
cpomarsion and one more try catch. I will try to separate it during review in all ways.

Best regards, J.


From bugzilla-daemon at icedtea.classpath.org  Wed Apr 25 02:16:52 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Wed, 25 Apr 2012 09:16:52 +0000
Subject: [Bug 911] Server minecraft crashed. that would make that work?
In-Reply-To: <bug-911-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-911-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-911-30-dsDqdBiMW7@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=911

Xerxes R?nby <xerxes at zafena.se> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
          Component|JamVM                       |IcedTea
            Version|6-hg                        |6-1.8.13
         Resolution|---                         |INVALID
           Severity|critical                    |normal

--- Comment #1 from Xerxes R?nby <xerxes at zafena.se> ---
You use a old version of icedtea6 1.8.13, built and packaged by debian
Distribution: Debian GNU/Linux 6.0.4 (squeeze), package 6b18-1.8.13-0+squeeze1

This version are currently not supported by the IcedTea team.
Please re-test using icedtea6 1.9.x , icedtea6 1.10.x or icedtea6 1.11.x.
Its possible that the bug have already been fixed by using the latest icedtea6
version.

Debian have built supported icedtea6 1.11.x versions in their wheezy testing
archive. Please provide a testcase, instructions, on how to reproduce this
crash using the minecraft server, if you still can reproduce this bug using any
of the last three icedtea6 versions.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120425/4aa74308/attachment.html 

From bugzilla-daemon at icedtea.classpath.org  Wed Apr 25 02:36:00 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Wed, 25 Apr 2012 09:36:00 +0000
Subject: [Bug 912] Pentaho Kettle' spoon.sh  fatal error, SIGSEGV
In-Reply-To: <bug-912-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-912-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-912-30-1gdLcaJ1zK@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=912

Xerxes R?nby <xerxes at zafena.se> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |xerxes at zafena.se
         Resolution|---                         |WORKSFORME

--- Comment #3 from Xerxes R?nby <xerxes at zafena.se> ---
I am unable to reproduce this bug using:
java version "1.6.0_24"
OpenJDK Runtime Environment (IcedTea6 1.11.1) (6b24-1.11.1-3ubuntu3)
OpenJDK Server VM (build 20.0-b12, mixed mode)
in combination with Pentaho Data Integration (Kettle) 4.2.0

Testcase:
wget
http://downloads.sourceforge.net/project/pentaho/Data%20Integration/4.2.0-stable/pdi-ce-4.2.0-stable.tar.gz?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fpentaho%2Ffiles%2FData%2520Integration%2F4.2.0-stable%2F&ts=1335346385&use_mirror=kent
tar zxvf pdi-ce-4.2.0-stable.tar.gz
cd data-integration
./spoon.sh

The eclipse based window open on my machine and I am able to load the examples.
Please reopen this bug if you can reproduce it using icedtea6 1.11.1 and later.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120425/9842a829/attachment.html 

From bugzilla-daemon at icedtea.classpath.org  Wed Apr 25 02:49:44 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Wed, 25 Apr 2012 09:49:44 +0000
Subject: [Bug 916] Minecraft server crash
In-Reply-To: <bug-916-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-916-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-916-30-tScrj6tNdJ@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=916

Xerxes R?nby <xerxes at zafena.se> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |xerxes at zafena.se
          Component|AddVM                       |IcedTea
           Hardware|x86                         |x86_64
            Version|unspecified                 |6-1.8.13
         Resolution|---                         |INVALID
           Assignee|doko at ubuntu.com             |unassigned at icedtea.classpat
                   |                            |h.org

--- Comment #1 from Xerxes R?nby <xerxes at zafena.se> ---
You use a old version of icedtea6 1.8.13, built and packaged by debian
Distribution: Debian GNU/Linux 6.0.4 (squeeze), package 6b18-1.8.13-0+squeeze1

This version are currently not supported by the IcedTea team.
Please re-test using icedtea6 1.9.x , icedtea6 1.10.x or icedtea6 1.11.x.
Its possible that the bug have already been fixed by using one of the latest
icedtea6 versions.

Debian have built a supported icedtea6 1.11.x version in their wheezy testing
archive.

If you still can reproduce this bug using one of the last three icedtea6
versions then lease provide a testcase, instructions, on how to setup and
reproduce this bug using the bukkit minecraft server,

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120425/203930e1/attachment.html 

From bugzilla-daemon at icedtea.classpath.org  Wed Apr 25 03:10:12 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Wed, 25 Apr 2012 10:10:12 +0000
Subject: [Bug 922] A fatal error has been detected by the Java Runtime
	Environment
In-Reply-To: <bug-922-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-922-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-922-30-sZfdmVLrxE@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=922

Xerxes R?nby <xerxes at zafena.se> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |xerxes at zafena.se
          Component|general                     |IcedTea
            Version|unspecified                 |6-1.11.1
         Resolution|---                         |INVALID
            Product|MIPS Port                   |IcedTea

--- Comment #1 from Xerxes R?nby <xerxes at zafena.se> ---
Hi, your error log indicates that the crash happened in the 
embedded web-browser in eclipse when the
libxul C code called from eclipse libswt jni code.

C  [libxul.so+0xd5076c]  NS_InvokeByIndex_P+0x5d90

[error occurred during error reporting (printing native stack), id 0xb]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  org.eclipse.swt.internal.mozilla.XPCOM._NS_NewLocalFile(II[I)I+0
j  org.eclipse.swt.internal.mozilla.XPCOM.NS_NewLocalFile(II[I)I+10
j 
org.eclipse.swt.browser.AppFileLocProvider.<init>(Ljava/lang/String;Ljava/lang/String;Z)V+94
j  org.eclipse.swt.browser.Mozilla.create(Lorg/eclipse/swt/widgets/Composite;I)


eclipse are known to crash in combination with xulrunner 2.0
and you got xulrunner-2 installed on your system.

I am closing this bug since the crash happened outside icedtea code.

the upstream eclipse bug also counts this crash as invalid
https://bugs.eclipse.org/bugs/show_bug.cgi?id=340998
"Closing report as invalid since pointing the Browser at a XULRunner install
with version >= 2.0 is not supported.  If you see any problems with embedding
of WebKitGTK then please open a new report, thanks."

You should get eclipse to stop crashing by using:
eclipse -vmargs -Xmx384m -Dorg.eclipse.swt.browser.UseWebKitGTK=true

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120425/6b538cdc/attachment.html 

From jvanek at redhat.com  Wed Apr 25 03:37:44 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Wed, 25 Apr 2012 12:37:44 +0200
Subject: [rfc] [icedtea-web] make links
In-Reply-To: <c3e9ac21-83bf-4316-9e9b-b305ddc609dd@zmail17.collab.prod.int.phx2.redhat.com>
References: <c3e9ac21-83bf-4316-9e9b-b305ddc609dd@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <4F97D3F8.3060401@redhat.com>

On 04/24/2012 05:07 PM, Andrew Hughes wrote:
> Comments on this patch:
>
> 1.  Why the changes to clean-local?  Was there a reason clean-bootstrap-directory
> needed to be earlier?
Omg. This would be regression. The change of order (to make it last) was done with signed applets 
tests. And was necessary. Without it cleaning of applets would fail.
I started to wrote this patch long before signed applets, so this was relict.
Thanx for catch!
> 2.  Is there a reason you're using MOZZILA_{GLOBAL,LOCAL}_BACKUP_FILE instead
> of MOZILLA_{LOCAL,GLOBAL}_BACKUP_FILE?  Thought it was a typo at first.
> 3.  "donot exists" should be "doesn't exist"
> 4.  Why the change to netx-unit-tests-compile?  Like 1, they seem unrelated
> to the rest of the patch.

True. This is unrelated but will be necessary soon. I will post as separate patch when needs come.
>
snip
>
> I don't think the restore ones should depend on the creation ones.
> It seems intuitive, but in my experience, it leads to problems in cleanup.
> They test for existence anyway.
I have removed this dependences. (As tehre is check, then I agree for sure)
>
> For the creation ones, you just need to make sure the plugin exists
> where it's expected to.  I don't think the current targets will do this
> as they just create it in the build directory.
I have added dependenci on $(DESTDIR)$(libdir)/$(BUILT_PLUGIN_LIBRARY). This should do what you want.
>
>>> 2.  You don't check that ${HOME}/.mozilla/plugins exists.
>> It should exists if some mozilla like browser is installed. And I'm
>> checking for installed browsers,
>> so this shouyld be ok.
>
> Only if the browser has been run by the user before.
This does not sounds true... I have tried and this  filesystems always come with browser.
>
>>> 3.  I think using ${HOME} as above may be safer than relying on
>>> tilde expansion by the shell.
>> fixed!
>
> So I see.  I like the use of common variables too.
>
>>> 4.  I don't think we need the messages.  They may have been useful
>>> for debugging but can now be removed.
>> I have removed the messages. But then I have extended it for "unlink"
>>   targets and it become quite
>> confusing. Soi I have added them back and now is clear what are those
>> manual targets doing. I'm for
>> to kept them inside (two levels of conditional branching CAN be
>> confusing).
>
> Looks a lot better.  Fine, other than the typo mentioned above.
typo fixed.
>
>>> 5.  The dependencies on the new targets seem excessive.  All you
>>> need is whatever dependency ensures
>>> the plugin has been installed.  You don't need e.g. javaws.desktop
>>> or docs.stamp because you don't use
>>> them.
>> fied
>
> Point 6...
>
>>> 6.  On that note, surely it should use the plugin from the build
>>> directory as people tend to run "make check"
>>> before "make install"?
>> 50% true, 50% not ;) (If I translated it correctly)
>>
>> make check and make run-netx-dist-tests are independent targets. Make
>> check should be run before
>> make install and have no linking work. But make run-netx-dist-tests
>> MUST have icedtea-wen installed
>> and MUST be run after make install, and is using those new linking
>> targets
>>
>> It give sense to me. (?)
>
> To me, I'd expect them to be part of make check as they're tests.
It can not be. It needs icedtea-web installed.
> I wouldn't expect anything to run after make install.
>
> A build I would expect to go:
>
> 1. configure
> 2. make
> 3. make check (optional)
> 4. make install
   5. make jtreg or test-instaleld-application or ...run-netx-dist-tests

This is really mentioned like testing of final application. netx installed, and plugin linked. It 
then launch javaws and browsers with testcases/reproducers....

jtreg suite is good comparison. it is doing approx. the same. Only our one  does not have gui and is 
integrated inside makefile.

There already was an idea to separate it or to remove this target utterly and to use some existing 
tool (eg jetreg). For now this target (with codecoverage after) is doing its job well.

If there really will come some  big refactoring , then it definitely will come as different changeset.

So I would like to consider this as unrelevant to this patch O:) (If I can be allowed )
>
> with 4 possibly being run by a different user at a completely different
> time (e.g. a user builds it then an admin installs it for them to the system).
> Or 4 could use DESTDIR to do a staged install.
>
> The main issue is your dependencies only create a situation after stage 2.
> It will break if you run make and then one of your test targets.

It will, and I'm hesitating with some restrictions/lightening or more conditional branching. Right 
now, it is practically dependent on make install. This should be enough. On the other side 
run-netx-dist-tests should be dependent on  make global-linkks (xor user-links), or the results of 
tests run will be unpredictable and possibly wrong. But we have agreed that it will not.
Unless I will force this dependence in again, then the only point leading to must of make 
*link/remove*link  will be hint in documentation  - probably in - 
http://icedtea.classpath.org/wiki/Reproducers (with which should be any icedtea-web developer 
familiar anyway;) )


>
> Why would you want to install it before testing it anyway?  I don't understand.
> The user tests could be run as part of make check IMHO, though you may need to
> use xvfb to run the browsers (as the jdk jtreg tests do).

Clarified (2x) above I hope.
>
>>>
snip
>>>
>>

changelog:
2012-04-25  Jiri Vanek<jvanek at redhat.com>

     	Added detection of installed browsers and added targets to create
    	symbolic links from install dir to browsers' plugin directories.
	 Primarily for testing purposes
     	*Makefile.am: (stamps/user-links.stamp) with alias (links) - new target for
     	creating symlinks for all users. One must be root to execute this target.
     	(stamps/global-links.stamp) with alias (user-links) - new target
     	for creating symlinks for logged user only. Because opera is missing this feature,
	 quite useless for testing or dependence targets, but good for live user.
  	(restore-global-links): target for restoring original global links.
  	One must be root again
  	(restore-user-links): target for restoring user's links
     	*configure.ac: added basic check whether and which browsers are
     	installed



Best regards, and thanx for review again ;)

J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: makeLinks3.diff
Type: text/x-patch
Size: 9727 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120425/b9c978de/makeLinks3.diff 

From jvanek at redhat.com  Wed Apr 25 05:07:09 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Wed, 25 Apr 2012 14:07:09 +0200
Subject: RFC - Reduce loading of PropertiesFile
In-Reply-To: <20120420150101.14915dxboe6rewb1@webmail.your-server.de>
References: <1334087640.1431.26.camel@localhost.localdomain>
	<4F86D475.5020202@redhat.com>
	<1334520186.1444.43.camel@localhost.localdomain>
	<4F8C1644.5090001@redhat.com>
	<1334862860.1435.15.camel@localhost.localdomain>
	<4F914FE3.2030109@redhat.com>
	<20120420150101.14915dxboe6rewb1@webmail.your-server.de>
Message-ID: <4F97E8ED.5000801@redhat.com>

On 04/20/2012 03:01 PM, Thomas Meyer wrote:
>
> Zitat von Jiri Vanek <jvanek at redhat.com>:
>
>> On 04/19/2012 09:14 PM, Thomas Meyer wrote:
>>
>>>
>>> patch1.diff
>>>
>>>
>>> # HG changeset patch
>>> # User Thomas Meyer<thomas at m3y3r.de>
>>> # Date 1334859522 -7200
>>> # Node ID e750944c8d66bbab0801e7490303eef26b689df3
>>> # Parent 4a35862de3fc26a9e1cdfb66fd7b6c750f18371b
>>> Enable JNLPRuntime class to run in headless mode
>>>
>>> diff -r 4a35862de3fc -r e750944c8d66 netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java
>>> --- a/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java Thu Apr 19 20:02:40 2012 +0200
>>> +++ b/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java Thu Apr 19 20:18:42 2012 +0200
>>> @@ -199,12 +199,14 @@
>>> ServiceManager.setServiceManagerStub(new XServiceManagerStub()); // ignored if we're running
>>> under Web Start
>>>
>>> policy = new JNLPPolicy();
>>> - security = new JNLPSecurityManager(); // side effect: create JWindow
>>> -
>>> - try {
>>> - UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
>>> - } catch (Exception e) {
>>> - // ignore it
>>> + if (!headless) {
>>> + security = new JNLPSecurityManager(); // side effect: create JWindow
>>> +
>>> + try {
>>> + UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
>>> + } catch (Exception e) {
>>> + // ignore it
>>> + }
>>> }
>>>
>>> doMainAppContextHacks();
>>>
>>>
>> hmhm. This looks un-relevant to original issue. What is motivation? Can you poist it in new patch?
>
> without this path the unit test fails in/after a call to JNLPRuntime.initialize() with a
> StackOverflowException.
>
> my solution was to disable the SecurityManager for headless mode. this made my unit test work.
> I'm not sure if this is the correct thing to do here! Help appriciated!
>

It is definitely wrong. We must have security manager in all times!

Correct think will be to set proper permissions and so allow start of security threads correctly 
(just guessing, right now digging deeper;)

J.


From adinn at redhat.com  Wed Apr 25 05:49:09 2012
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 25 Apr 2012 13:49:09 +0100
Subject: ARM: Support for JVMTI notifications from JIT compiler on code
	generation
Message-ID: <4F97F2C5.1020802@redhat.com>

This is a patch against
http://icedtea.classpath.org/hg/release/icedtea7-forest-2.1/hotspot

It modifies the ARM JIT to post JVMTI events whenever native code is
generated from Java method bytecode, providing details of the class
andmethod name, the generated code address range and a mapping from
address subranges to bytecode indices. That's enough to allow oprofile
to provide line by line profiling information.

This has been tested with the oprofile Java agent and the resulting
behaviour appears to be compatible with behaviour on x86. However, this
is not a full test as oprofile is not fully working in the latest
available ARM kernel. This means that the data generated by the agent in
response to the JVMTI events has not yet been properly consumed and
processed.

I have asked Andrew Haley to review this patch.

regards,


Andrew Dinn
-----------

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.txt
Url: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120425/ff253d94/patch.txt 

From jvanek at redhat.com  Wed Apr 25 05:55:55 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Wed, 25 Apr 2012 14:55:55 +0200
Subject: RFC - Reduce loading of PropertiesFile
In-Reply-To: <4F97E8ED.5000801@redhat.com>
References: <1334087640.1431.26.camel@localhost.localdomain>
	<4F86D475.5020202@redhat.com>
	<1334520186.1444.43.camel@localhost.localdomain>
	<4F8C1644.5090001@redhat.com>
	<1334862860.1435.15.camel@localhost.localdomain>
	<4F914FE3.2030109@redhat.com>
	<20120420150101.14915dxboe6rewb1@webmail.your-server.de>
	<4F97E8ED.5000801@redhat.com>
Message-ID: <4F97F45B.2080303@redhat.com>

On 04/25/2012 02:07 PM, Jiri Vanek wrote:
> On 04/20/2012 03:01 PM, Thomas Meyer wrote:
>>
>> Zitat von Jiri Vanek <jvanek at redhat.com>:
>>
>>> On 04/19/2012 09:14 PM, Thomas Meyer wrote:
>>>
>>>>
>>>> patch1.diff
>>>>
>>>>
>>>> # HG changeset patch
>>>> # User Thomas Meyer<thomas at m3y3r.de>
>>>> # Date 1334859522 -7200
>>>> # Node ID e750944c8d66bbab0801e7490303eef26b689df3
>>>> # Parent 4a35862de3fc26a9e1cdfb66fd7b6c750f18371b
>>>> Enable JNLPRuntime class to run in headless mode
>>>>
>>>> diff -r 4a35862de3fc -r e750944c8d66 netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java
>>>> --- a/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java Thu Apr 19 20:02:40 2012 +0200
>>>> +++ b/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java Thu Apr 19 20:18:42 2012 +0200
>>>> @@ -199,12 +199,14 @@
>>>> ServiceManager.setServiceManagerStub(new XServiceManagerStub()); // ignored if we're running
>>>> under Web Start
>>>>
>>>> policy = new JNLPPolicy();
>>>> - security = new JNLPSecurityManager(); // side effect: create JWindow
>>>> -
>>>> - try {
>>>> - UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
>>>> - } catch (Exception e) {
>>>> - // ignore it
>>>> + if (!headless) {
>>>> + security = new JNLPSecurityManager(); // side effect: create JWindow
>>>> +
>>>> + try {
>>>> + UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
>>>> + } catch (Exception e) {
>>>> + // ignore it
>>>> + }
>>>> }
>>>>
>>>> doMainAppContextHacks();
>>>>
>>>>
>>> hmhm. This looks un-relevant to original issue. What is motivation? Can you poist it in new patch?
>>
>> without this path the unit test fails in/after a call to JNLPRuntime.initialize() with a
>> StackOverflowException.
>>
>> my solution was to disable the SecurityManager for headless mode. this made my unit test work.
>> I'm not sure if this is the correct thing to do here! Help appriciated!
>>
>
> It is definitely wrong. We must have security manager in all times!
>
> Correct think will be to set proper permissions and so allow start of security threads correctly
> (just guessing, right now digging deeper;)
>
> J.

In your original test, you have forgot to JNLPRuntime.setSecurityEnabled(false). But still.. it will 
cause issues with properties and avalanche of other issues. See my suggested  change in attachment 
(just got rid of jnlp runtime and fake recently_used path)

Please, under any circumstances do not push this changeset!o)

Bets regards, and hope that faked path will  help!
J.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: tmPatch2minus1.diff
Type: text/x-patch
Size: 4387 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120425/6edc16c0/tmPatch2minus1.diff 

From aph at redhat.com  Wed Apr 25 06:28:38 2012
From: aph at redhat.com (Andrew Haley)
Date: Wed, 25 Apr 2012 14:28:38 +0100
Subject: ARM: Support for JVMTI notifications from JIT compiler on code
	generation
In-Reply-To: <4F97F2C5.1020802@redhat.com>
References: <4F97F2C5.1020802@redhat.com>
Message-ID: <4F97FC06.8070404@redhat.com>

On 04/25/2012 01:49 PM, Andrew Dinn wrote:
> This is a patch against
> http://icedtea.classpath.org/hg/release/icedtea7-forest-2.1/hotspot
> 
> It modifies the ARM JIT to post JVMTI events whenever native code is
> generated from Java method bytecode, providing details of the class
> andmethod name, the generated code address range and a mapping from
> address subranges to bytecode indices. That's enough to allow oprofile
> to provide line by line profiling information.
> 
> This has been tested with the oprofile Java agent and the resulting
> behaviour appears to be compatible with behaviour on x86. However, this
> is not a full test as oprofile is not fully working in the latest
> available ARM kernel. This means that the data generated by the agent in
> response to the JVMTI events has not yet been properly consumed and
> processed.
> 
> I have asked Andrew Haley to review this patch.

But if anyone else wants to join in...

> diff -r a5d04cb60a5c -r fada6a7d5e89 src/cpu/zero/vm/thumb2.cpp
> --- a/src/cpu/zero/vm/thumb2.cpp	Wed Apr 11 09:24:03 2012 -0400
> +++ b/src/cpu/zero/vm/thumb2.cpp	Wed Apr 25 13:43:33 2012 +0100
> @@ -440,6 +440,12 @@
>  unsigned stack[1000];
>  unsigned r_local[1000];
>  
> +// jvmti needs to map start address of generated code for a bytecode
> +// to corrsponding bytecode index so agents can correlate code address
> +// ranges with bci and thence line number
> +jvmtiAddrLocationMap address_bci_map[THUMB2_MAX_BYTECODE_SIZE];

I presume that there need only be one of these because it is only
accessed under lock.  However, it's 160kbytes in size.  It
might be a better idea to allocate the space at runtime: not every
VM runs the JIT.

>    jinfo_str.code_base = code_base;
> @@ -7580,6 +7597,27 @@
>    if (compiled_offset == 0) return 0;
>    thumb_entry.compiled_entrypoint = slow_entry + compiled_offset;
>    thumb_entry.osr_entry = (unsigned)cmethod->osr_entry | TBIT;
> +  {
> +    // we need to notify a Jvmti compiled_method_load event
> +
> +    // notify the whole generated code region for this Java method
> +    // from slow_entry through to the end of the osr table. some
> +    // of it is data not code but that's not a problem.

I have a personal preference for sentences in comments.


> +
> +    const void *gen_code_start = (const void *)(slow_entry ^ TBIT);
> +    unsigned gen_code_size = codebuf_str.idx * 2;
> +
> +    // address_bci_map translates start addresses for generated code
> +    // sections to bytecode indices
> +
> +    // the final compile_info argument is supposed to contain
> +    // information about inlined code. we can supply NULL for now -
> +    // oprofile doesn't use it anyway
> +
> +    void *compile_info = NULL;
> +
> +    JvmtiExport::post_compiled_method_load(method, gen_code_size, gen_code_start, address_bci_map_length, address_bci_map, NULL);

Please avoid lines so long that they wrap.

> +  }
>    return *(unsigned long long *)&thumb_entry;
>  }
>  
> diff -r a5d04cb60a5c -r fada6a7d5e89 src/share/vm/prims/jvmtiExport.cpp
> --- a/src/share/vm/prims/jvmtiExport.cpp	Wed Apr 11 09:24:03 2012 -0400
> +++ b/src/share/vm/prims/jvmtiExport.cpp	Wed Apr 25 13:43:33 2012 +0100
> @@ -1776,6 +1776,48 @@
>    }
>  }
>  
> +#ifdef __arm__
> +
> +// special compiled_method_load notify API for thumb2 compiler
> +
> +void JvmtiExport::post_compiled_method_load(const methodOop method, const jint length,
> +                                            const void *code_begin, const jint map_length,
> +                                            const jvmtiAddrLocationMap* map,
> +					    const void *compile_info)
> +{
> +  JavaThread* thread = JavaThread::current();
> +  jmethodID methodId = method->jmethod_id();
> +
> +  EVT_TRIG_TRACE(JVMTI_EVENT_COMPILED_METHOD_LOAD,
> +                 ("JVMTI [%s] method compile load event triggered (by thumb2_compile)",
> +                 JvmtiTrace::safe_get_thread_name(thread)));
> +
> +  JvmtiEnvIterator it;
> +  for (JvmtiEnv* env = it.first(); env != NULL; env = it.next(env)) {
> +    if (env->is_enabled(JVMTI_EVENT_COMPILED_METHOD_LOAD)) {
> +
> +      EVT_TRACE(JVMTI_EVENT_COMPILED_METHOD_LOAD,
> +                ("JVMTI [%s] class compile method load event sent %s.%s   (by thumb2_compile)",
> +                JvmtiTrace::safe_get_thread_name(thread),
> +                method->klass_name()->as_C_string(),
> +		 method->name()->as_C_string()));
> +
> +      // I think we need this to add a resource mark and handle for
> +      // the thread and record a vm to native (agent lib) transition
> +
> +      JvmtiJavaThreadEventTransition jet(thread);
> +      jvmtiEventCompiledMethodLoad callback = env->callbacks()->CompiledMethodLoad;
> +
> +      if (callback != NULL) {
> +        (*callback)(env->jvmti_external(), methodId,
> +                    length, code_begin, map_length,
> +                    map, compile_info);
> +      }
> +    }
> +  }
> +}
> +
> +#endif // __arm__

This is a bit unfortunate.  I presume we have to do it because JvmtiExport
doesn't give us what we need.

Andrew.


From jvanek at redhat.com  Wed Apr 25 06:39:37 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Wed, 25 Apr 2012 15:39:37 +0200
Subject: [rfc] [icedtea-web] make links
In-Reply-To: <4F97D3F8.3060401@redhat.com>
References: <c3e9ac21-83bf-4316-9e9b-b305ddc609dd@zmail17.collab.prod.int.phx2.redhat.com>
	<4F97D3F8.3060401@redhat.com>
Message-ID: <4F97FE99.1020805@redhat.com>

Hi Andrew, I just realized that I forgot to send opera;firefox... string to code coverage. This 
patch is add-one-line boosted makeLInks3 i sent few hours ago. Thanx and sorry
J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: makeLinks4.diff
Type: text/x-patch
Size: 10049 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120425/29bdbe39/makeLinks4.diff 

From dbhole at redhat.com  Wed Apr 25 06:49:37 2012
From: dbhole at redhat.com (Deepak Bhole)
Date: Wed, 25 Apr 2012 09:49:37 -0400
Subject: /hg/icedtea-web: Spelling fixes
In-Reply-To: <20120425094746.17236ey7mmvth1r6@webmail.your-server.de>
References: <fa59594e-112b-4644-8b67-a18a794f1d88@zmail17.collab.prod.int.phx2.redhat.com>
	<20120425094746.17236ey7mmvth1r6@webmail.your-server.de>
Message-ID: <20120425134937.GA15741@redhat.com>

* Thomas Meyer <thomas at m3y3r.de> [2012-04-25 04:04]:
> 
> Zitat von Andrew Hughes <ahughes at redhat.com>:
> >----- Original Message -----
> >>diffstat:
> >>
> >> tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java |
> >>  106 ++++-----
> >> 1 files changed, 52 insertions(+), 54 deletions(-)
> >>
> >
> >This change needs a ChangeLog entry.
> >
> >Was it reviewed on the list?
> 
> Yes, it was. Also somebody told me, that this kind of change doesn't
> need a review.
> 
> >I don't see a review, but may have missed it.
> >Given it's just typo corrections, it can probably go in as trivial.  But it
> >does need a ChangeLog.
> 
> Okay, I didn't know that. So every change needs a Changelog entry,
> sound sensible :-) Should I add an entry for this change to the
> Changelog?
> 
> PS: Why is the Changelog needed at all? The source code is under
> control of mercurial, so you have a changelog anyway?
> 

Personally I find it useful if I have to go back and look at some
patchset to try and understand what was changed/why it was changed.

Cheers,
Deepak
> 


From dbhole at redhat.com  Wed Apr 25 06:51:23 2012
From: dbhole at redhat.com (Deepak Bhole)
Date: Wed, 25 Apr 2012 09:51:23 -0400
Subject: /hg/icedtea-web: Spelling fixes
In-Reply-To: <fa59594e-112b-4644-8b67-a18a794f1d88@zmail17.collab.prod.int.phx2.redhat.com>
References: <hg.a1c138829627.1334935216.8643924302249223276@icedtea.classpath.org>
	<fa59594e-112b-4644-8b67-a18a794f1d88@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <20120425135122.GB15741@redhat.com>

* Andrew Hughes <ahughes at redhat.com> [2012-04-24 20:41]:
> 
> 
> ----- Original Message -----
> > changeset a1c138829627 in /hg/icedtea-web
> > details:
> > http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=a1c138829627
> > author: Thomas Meyer <thomas at m3y3r.de>
> > date: Fri Apr 20 17:17:59 2012 +0200
> > 
> > 	Spelling fixes
> > 
> > 
> > diffstat:
> > 
> >  tests/netx/jnlp_testsengine/net/sourceforge/jnlp/ServerAccess.java |
> >   106 ++++-----
> >  1 files changed, 52 insertions(+), 54 deletions(-)
> > 
> 
> This change needs a ChangeLog entry.
> 
> Was it reviewed on the list?  I don't see a review, but may have missed it.
> Given it's just typo corrections, it can probably go in as trivial.  But it
> does need a ChangeLog.

Omair and I were just talking about this on IRC yesterday. I have always
used changelog to understand why certain changes were made in the past
(or when reviewing). 

However in this case, the only changes were to fix typos and the commit
message covers that. Is there a reason why we would still need a
changelog entry then?

Cheers,
Deepak

> -- 
> Andrew :)
> 
> Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
> 
> PGP Key: 248BDC07 (https://keys.indymedia.org/)
> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07
> 


From adinn at redhat.com  Wed Apr 25 07:28:16 2012
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 25 Apr 2012 15:28:16 +0100
Subject: ARM: Support for JVMTI notifications from JIT compiler on code
	generation
In-Reply-To: <4F97FC06.8070404@redhat.com>
References: <4F97F2C5.1020802@redhat.com> <4F97FC06.8070404@redhat.com>
Message-ID: <4F980A00.3000401@redhat.com>

On 25/04/12 14:28, Andrew Haley wrote:
>> I have asked Andrew Haley to review this patch.
> 
> But if anyone else wants to join in...

Of course, all feedback is welcome.

>> diff -r a5d04cb60a5c -r fada6a7d5e89 src/cpu/zero/vm/thumb2.cpp
>> --- a/src/cpu/zero/vm/thumb2.cpp	Wed Apr 11 09:24:03 2012 -0400
>> +++ b/src/cpu/zero/vm/thumb2.cpp	Wed Apr 25 13:43:33 2012 +0100
>> @@ -440,6 +440,12 @@
>>  unsigned stack[1000];
>>  unsigned r_local[1000];
>>  
>> +// jvmti needs to map start address of generated code for a bytecode
>> +// to corrsponding bytecode index so agents can correlate code address
>> +// ranges with bci and thence line number
>> +jvmtiAddrLocationMap address_bci_map[THUMB2_MAX_BYTECODE_SIZE];
> 
> I presume that there need only be one of these because it is only
> accessed under lock.  However, it's 160kbytes in size.  It
> might be a better idea to allocate the space at runtime: not every
> VM runs the JIT.

Yes, will do so.

>>    jinfo_str.code_base = code_base;
>> @@ -7580,6 +7597,27 @@
>>    if (compiled_offset == 0) return 0;
>>    thumb_entry.compiled_entrypoint = slow_entry + compiled_offset;
>>    thumb_entry.osr_entry = (unsigned)cmethod->osr_entry | TBIT;
>> +  {
>> +    // we need to notify a Jvmti compiled_method_load event
>> +
>> +    // notify the whole generated code region for this Java method
>> +    // from slow_entry through to the end of the osr table. some
>> +    // of it is data not code but that's not a problem.
> 
> I have a personal preference for sentences in comments.

By my reading the opening 2 lines of the second comment /are/ a sentence
(with a verb in the imperative mood). of course, your mileage (and
grammar) may vary.

I am happy to add a full stop after the sentence in the first comment
and some ','s to place  the 'not code' properly in apposition if you like.

>> +
>> +    const void *gen_code_start = (const void *)(slow_entry ^ TBIT);
>> +    unsigned gen_code_size = codebuf_str.idx * 2;
>> +
>> +    // address_bci_map translates start addresses for generated code
>> +    // sections to bytecode indices
>> +
>> +    // the final compile_info argument is supposed to contain
>> +    // information about inlined code. we can supply NULL for now -
>> +    // oprofile doesn't use it anyway
>> +
>> +    void *compile_info = NULL;
>> +
>> +    JvmtiExport::post_compiled_method_load(method, gen_code_size, gen_code_start, address_bci_map_length, address_bci_map, NULL);
> 
> Please avoid lines so long that they wrap.

Indeed.

>> +  }
>>    return *(unsigned long long *)&thumb_entry;
>>  }
>>  
>> diff -r a5d04cb60a5c -r fada6a7d5e89 src/share/vm/prims/jvmtiExport.cpp
>> --- a/src/share/vm/prims/jvmtiExport.cpp	Wed Apr 11 09:24:03 2012 -0400
>> +++ b/src/share/vm/prims/jvmtiExport.cpp	Wed Apr 25 13:43:33 2012 +0100
>> @@ -1776,6 +1776,48 @@
>>    }
>>  }
>>  
>> +#ifdef __arm__
>> +
>> +// special compiled_method_load notify API for thumb2 compiler
>> +
>> +void JvmtiExport::post_compiled_method_load(const methodOop method, const jint length,
>> +                                            const void *code_begin, const jint map_length,
>> +                                            const jvmtiAddrLocationMap* map,
>> +					    const void *compile_info)
>> +{
>> +  JavaThread* thread = JavaThread::current();
>> +  jmethodID methodId = method->jmethod_id();
>> +
>> +  EVT_TRIG_TRACE(JVMTI_EVENT_COMPILED_METHOD_LOAD,
>> +                 ("JVMTI [%s] method compile load event triggered (by thumb2_compile)",
>> +                 JvmtiTrace::safe_get_thread_name(thread)));
>> +
>> +  JvmtiEnvIterator it;
>> +  for (JvmtiEnv* env = it.first(); env != NULL; env = it.next(env)) {
>> +    if (env->is_enabled(JVMTI_EVENT_COMPILED_METHOD_LOAD)) {
>> +
>> +      EVT_TRACE(JVMTI_EVENT_COMPILED_METHOD_LOAD,
>> +                ("JVMTI [%s] class compile method load event sent %s.%s   (by thumb2_compile)",
>> +                JvmtiTrace::safe_get_thread_name(thread),
>> +                method->klass_name()->as_C_string(),
>> +		 method->name()->as_C_string()));
>> +
>> +      // I think we need this to add a resource mark and handle for
>> +      // the thread and record a vm to native (agent lib) transition
>> +
>> +      JvmtiJavaThreadEventTransition jet(thread);
>> +      jvmtiEventCompiledMethodLoad callback = env->callbacks()->CompiledMethodLoad;
>> +
>> +      if (callback != NULL) {
>> +        (*callback)(env->jvmti_external(), methodId,
>> +                    length, code_begin, map_length,
>> +                    map, compile_info);
>> +      }
>> +    }
>> +  }
>> +}
>> +
>> +#endif // __arm__
> 
> This is a bit unfortunate.  I presume we have to do it because JvmtiExport
> doesn't give us what we need.

Yes, the client API method provided for the other compilers expects an
nmethod instance so using it would drag us into creating nmethods which
means supporting the full AbstractCompiler lifecycle.

There is another API method which is provided for use if you already
have a handle on a JvmtiEnv -- not sure where it is actually used but I
think it is intended for agent implementations to use. Using it would
require the ARM JIT code to do the iteration over the JvmtiEnv list and
I regarded that as something which ought to be kept internal to
JvmtiExport. Hence the invention of this new API method.

I am not certain about the value of the declared
JvmtiJavaThreadEventTransition. I am assuming that it is needd to retain
a handle on the thread when we enter into JVMI agent code in case of
either GCs or exceptions. Perhaps someone can comment on whether this is
i) necessary and ii) sufficient (e.g. do we also need to declare a
HandleMark for the methodOop?).

regards,


Andrew Dinn
-----------


From aph at redhat.com  Wed Apr 25 07:33:20 2012
From: aph at redhat.com (Andrew Haley)
Date: Wed, 25 Apr 2012 15:33:20 +0100
Subject: ARM: Support for JVMTI notifications from JIT compiler on code
	generation
In-Reply-To: <4F980A00.3000401@redhat.com>
References: <4F97F2C5.1020802@redhat.com> <4F97FC06.8070404@redhat.com>
	<4F980A00.3000401@redhat.com>
Message-ID: <4F980B30.2080908@redhat.com>

On 04/25/2012 03:28 PM, Andrew Dinn wrote:
> On 25/04/12 14:28, Andrew Haley wrote:

>>>    jinfo_str.code_base = code_base;
>>> @@ -7580,6 +7597,27 @@
>>>    if (compiled_offset == 0) return 0;
>>>    thumb_entry.compiled_entrypoint = slow_entry + compiled_offset;
>>>    thumb_entry.osr_entry = (unsigned)cmethod->osr_entry | TBIT;
>>> +  {
>>> +    // we need to notify a Jvmti compiled_method_load event
>>> +
>>> +    // notify the whole generated code region for this Java method
>>> +    // from slow_entry through to the end of the osr table. some
>>> +    // of it is data not code but that's not a problem.
>>
>> I have a personal preference for sentences in comments.
> 
> By my reading the opening 2 lines of the second comment /are/ a sentence
> (with a verb in the imperative mood). of course, your mileage (and
> grammar) may vary.
> 
> I am happy to add a full stop after the sentence in the first comment
> and some ','s to place  the 'not code' properly in apposition if you like.

Full stops and capitals are nice.  But what does
"we need to notify a Jvmti compiled_method_load event" refer to?
What is being notified?  I'm not being arsey, I really don't
understand this comment.

>> This is a bit unfortunate.  I presume we have to do it because JvmtiExport
>> doesn't give us what we need.
> 
> Yes, the client API method provided for the other compilers expects an
> nmethod instance so using it would drag us into creating nmethods which
> means supporting the full AbstractCompiler lifecycle.

I see.

> There is another API method which is provided for use if you already
> have a handle on a JvmtiEnv -- not sure where it is actually used but I
> think it is intended for agent implementations to use. Using it would
> require the ARM JIT code to do the iteration over the JvmtiEnv list and
> I regarded that as something which ought to be kept internal to
> JvmtiExport. Hence the invention of this new API method.

OK.

> I am not certain about the value of the declared
> JvmtiJavaThreadEventTransition. I am assuming that it is needd to retain
> a handle on the thread when we enter into JVMI agent code in case of
> either GCs or exceptions. Perhaps someone can comment on whether this is
> i) necessary and ii) sufficient (e.g. do we also need to declare a
> HandleMark for the methodOop?).

Ewww.  Dunno, sorry.  Perhaps it couldn't hurt?

Andrew.



From adinn at redhat.com  Wed Apr 25 07:51:39 2012
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 25 Apr 2012 15:51:39 +0100
Subject: ARM: Support for JVMTI notifications from JIT compiler on code
	generation
In-Reply-To: <4F980B30.2080908@redhat.com>
References: <4F97F2C5.1020802@redhat.com> <4F97FC06.8070404@redhat.com>
	<4F980A00.3000401@redhat.com> <4F980B30.2080908@redhat.com>
Message-ID: <4F980F7B.5040709@redhat.com>

On 25/04/12 15:33, Andrew Haley wrote:
> +    // we need to notify a Jvmti compiled_method_load event
> . . .
> Full stops and capitals are nice.  But what does
> "we need to notify a Jvmti compiled_method_load event" refer to?
> What is being notified?  I'm not being arsey, I really don't
> understand this comment.

Ah, I see where you are confused now. The comment is indeed elliptical.
Fully qualified it would be 'we need to notify a  Jvmti
compiled_method_load event to the Jvmti agent associated with this
JvmtiEnv'. I acknowledge that's 'notifying an event to a client' is a
rather jargon-tinged (actually more realistically -tanned) usage of the
verb 'notify'. Since you didn't follow it I'll take that as evidence of
inadequacy and rephrase as follows:

// we need to dispatch a compiled_method_load event
// to all registered Jvmti agents


regards,


Andrew Dinn
-----------


From aph at redhat.com  Wed Apr 25 07:52:27 2012
From: aph at redhat.com (Andrew Haley)
Date: Wed, 25 Apr 2012 15:52:27 +0100
Subject: ARM: Support for JVMTI notifications from JIT compiler on code
	generation
In-Reply-To: <4F980F7B.5040709@redhat.com>
References: <4F97F2C5.1020802@redhat.com> <4F97FC06.8070404@redhat.com>
	<4F980A00.3000401@redhat.com> <4F980B30.2080908@redhat.com>
	<4F980F7B.5040709@redhat.com>
Message-ID: <4F980FAB.10004@redhat.com>

On 04/25/2012 03:51 PM, Andrew Dinn wrote:
> Since you didn't follow it I'll take that as evidence of
> inadequacy and rephrase as follows:
> 
> // we need to dispatch a compiled_method_load event
> // to all registered Jvmti agents

Excellent.  I'd still prefer full stops and capitals.  Maybe
I'm old-fashioned.  :-)

Andrew.


From adinn at redhat.com  Wed Apr 25 07:55:38 2012
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 25 Apr 2012 15:55:38 +0100
Subject: ARM: Support for JVMTI notifications from JIT compiler on code
	generation
In-Reply-To: <4F980FAB.10004@redhat.com>
References: <4F97F2C5.1020802@redhat.com> <4F97FC06.8070404@redhat.com>
	<4F980A00.3000401@redhat.com> <4F980B30.2080908@redhat.com>
	<4F980F7B.5040709@redhat.com> <4F980FAB.10004@redhat.com>
Message-ID: <4F98106A.706@redhat.com>

On 25/04/12 15:52, Andrew Haley wrote:
> Excellent.  I'd still prefer full stops and capitals.  Maybe
> I'm old-fashioned.  :-)

Well, I don't know about you but at my age it's hard to be anything but
old-fashioned.

regards,


Andrew Dinn
-----------


From jvanek at redhat.com  Wed Apr 25 08:03:39 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Wed, 25 Apr 2012 17:03:39 +0200
Subject: [rfc][icedtea-web] Bug annotation
Message-ID: <4F98124B.5050705@redhat.com>

Hi all!
4/5 of  browser testing framework. This one is not related to testing of applets in browsers, but is 
extension to testing framework as a complex. I got inspired by jtreg and by Pavel and our 
documentaries  who are always annoyed when tracking some bug in icedtea-web.

This was originally purposed by me in  Extending jnlp reproducers for html+applet reproducers in 
March [1]:

*@Bug* annotation  - can handle IDs of bugs or urls to web which contains more info about "why this
reproducer or unit test was added", are *nicely* propagated also to html report (see attached
report.zip). Name convention is as we are used to from NEWS files."


[1] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-March/017799.html


Best regars
J.

changelog

2012-04-25  Jiri Vanek  <jvanek at redhat.com>

	Introduced new annotations Bug (to connect test/reproducer with documentation) and NeedsDisplay 
which tells the launching engine that this particular test needs Display. Based on ptisnovs's ideas 
and jtreg experiences
	*Makefile.am: (JUNIT_RUNNER_JAR), (stamps/run-netx-unit-tests.stamp) and
(stamps/run-unit-test-code-coverage.stamp) are now dependent on (stamps/netx-dist-tests-compile) and 
classpaths inside them have been enriched for JNLP_TESTS_ENGINE_DIRwhich contains definitions of 
those annotations
	*tests/jnlp_tests/simple/CheckServices/testcases/CheckServicesTests.java: and
	*tests/jnlp_tests/simple/ManifestedJar1/testcases/ManifestedJar1Test.java: and
	*tests/jnlp_tests/simple/Spaces can be everywhere/testcase/SpacesCanBeEverywhereTests.java: filled 
Bug annotations
	*tests/junit-runner/JunitLikeXmlOutputListener.java: made to understand Bug annotation
	*tests/netx/jnlp_testsengine/net/sourceforge/jnlp/annotations/NeedsDisplay.java: and
	*tests/netx/jnlp_testsengine/net/sourceforge/jnlp/annotations/Bug.java: annotations definitions
	*tests/report-styles/jreport.xsl" made nice links from bug annotation prepared by
JunitLikeXmlOutputListener

-------------- next part --------------
A non-text attachment was scrubbed...
Name: report.zip
Type: application/zip
Size: 10967 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120425/efa332d5/report.zip 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bugAnnotation.diff
Type: text/x-patch
Size: 18159 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120425/efa332d5/bugAnnotation.diff 

From bugzilla-daemon at icedtea.classpath.org  Wed Apr 25 23:23:10 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Thu, 26 Apr 2012 06:23:10 +0000
Subject: [Bug 963] New: An unexpected error has been detected by Java Runtime
	Environment:
Message-ID: <bug-963-30@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=963

          Priority: P3
            Bug ID: 963
          Assignee: unassigned at icedtea.classpath.org
           Summary: An unexpected error has been detected by Java Runtime
                    Environment:
          Severity: major
    Classification: Unclassified
                OS: Linux
          Reporter: dharma at bsmart.my
          Hardware: 64-bit
            Status: NEW
           Version: unspecified
         Component: IcedTea
           Product: IcedTea

Created attachment 681
  --> http://icedtea.classpath.org/bugzilla/attachment.cgi?id=681&action=edit
Error log file

Hi,

We need help as this happens once a month a we have not solution for it, please
help us. All error captured in the attached log file.

Thank you for your kind help.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120426/a8c8d171/attachment.html 

From bugzilla-daemon at icedtea.classpath.org  Thu Apr 26 06:34:06 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Thu, 26 Apr 2012 13:34:06 +0000
Subject: [Bug 886] 6-1.11.1 fails to build CACAO on ppc
In-Reply-To: <bug-886-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-886-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-886-30-LuTPEGGGZ9@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=886

Xerxes R?nby <xerxes at zafena.se> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |6-1.12

--- Comment #4 from Xerxes R?nby <xerxes at zafena.se> ---
This bug have been fixed in the icedtea6 hg and are to be released with
icedtea6-1.12
http://icedtea.classpath.org/hg/icedtea6/rev/a89d8bca422d

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120426/fd7d6019/attachment.html 

From bugzilla-daemon at icedtea.classpath.org  Thu Apr 26 06:46:19 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Thu, 26 Apr 2012 13:46:19 +0000
Subject: [Bug 887] The bug for minecraft server on linux
In-Reply-To: <bug-887-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-887-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-887-30-MQwNTrvd76@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=887

Xerxes R?nby <xerxes at zafena.se> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xerxes at zafena.se

--- Comment #1 from Xerxes R?nby <xerxes at zafena.se> ---
#  Internal Error (synchronizer.cpp:1954), pid=19400, tid=1185553296
#  guarantee(mid->header()->is_neutral()) failed: invariant

Oracle are aware of this bug, unfortunately no fix are found yet:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7085976

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120426/9b728d4f/attachment.html 

From bugzilla-daemon at icedtea.classpath.org  Thu Apr 26 06:51:06 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Thu, 26 Apr 2012 13:51:06 +0000
Subject: [Bug 887] The bug for minecraft server on linux
In-Reply-To: <bug-887-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-887-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-887-30-4IvY7dMKWa@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=887

--- Comment #2 from Xerxes R?nby <xerxes at zafena.se> ---
Actually this bug migt have been fixed in hs21:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6840152

Test if by adding -XX:-UseBiasedLocking would make your jvm to run more stable.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120426/3b5b7ff9/attachment.html 

From bugzilla-daemon at icedtea.classpath.org  Thu Apr 26 07:23:40 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Thu, 26 Apr 2012 14:23:40 +0000
Subject: [Bug 963] An unexpected error has been detected by Java Runtime
	Environment:
In-Reply-To: <bug-963-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-963-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-963-30-RtG8ulRdPG@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=963

Andrew Haley <aph at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |aph at redhat.com
         Resolution|---                         |INVALID

--- Comment #1 from Andrew Haley <aph at redhat.com> ---
I am afraid that this is a very old version of OpenJDK.

You really should not be running it.  Apart from anything else, there have been
many important security fixes.  Please upgrade to the current version and try
again.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120426/fdbc8872/attachment.html 

From bugzilla-daemon at icedtea.classpath.org  Thu Apr 26 07:28:46 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Thu, 26 Apr 2012 14:28:46 +0000
Subject: [Bug 887] The bug for minecraft server on linux
In-Reply-To: <bug-887-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-887-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-887-30-O5lWeXvnTm@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=887

--- Comment #3 from Xerxes R?nby <xerxes at zafena.se> ---
Adding another upstream bugreport
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6781744

It is possible that a backport of:
http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/c08677f98289
into icedtea6 would fix this issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120426/170e03ff/attachment.html 

From bugzilla-daemon at icedtea.classpath.org  Thu Apr 26 07:30:49 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Thu, 26 Apr 2012 14:30:49 +0000
Subject: [Bug 887] The bug for minecraft server on linux
In-Reply-To: <bug-887-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-887-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-887-30-wXGBG8ySMU@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=887

Stefan Ring <stefan at complang.tuwien.ac.at> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |stefan at complang.tuwien.ac.a
                   |                            |t

--- Comment #4 from Stefan Ring <stefan at complang.tuwien.ac.at> ---
(In reply to comment #2)
> Actually this bug migt have been fixed in hs21:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6840152

I don't see UseFastLocking or UseHeavyMonitors requested anywhere (I assume
they're -XX options), so I don't think there's a connection to the latter bug
id.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120426/326e4149/attachment.html 

From ptisnovs at icedtea.classpath.org  Thu Apr 26 07:31:45 2012
From: ptisnovs at icedtea.classpath.org (ptisnovs at icedtea.classpath.org)
Date: Thu, 26 Apr 2012 14:31:45 +0000
Subject: /hg/gfx-test: * src/org/gfxtest/testsuites/ClippingPathByRoundRe...
Message-ID: <hg.42228d31389e.1335450705.-6248649288953172555@icedtea.classpath.org>

changeset 42228d31389e in /hg/gfx-test
details: http://icedtea.classpath.org/hg/gfx-test?cmd=changeset;node=42228d31389e
author: Pavel Tisnovsky <ptisnovs at redhat.com>
date: Thu Apr 26 16:34:11 2012 +0200

	* src/org/gfxtest/testsuites/ClippingPathByRoundRectangleShape.java:
	  Added new tests to this test suite.


diffstat:

 ChangeLog                                                         |    5 +
 src/org/gfxtest/testsuites/ClippingPathByRoundRectangleShape.java |  262 +++++++++-
 2 files changed, 247 insertions(+), 20 deletions(-)

diffs (298 lines):

diff -r 905b20725f80 -r 42228d31389e ChangeLog
--- a/ChangeLog	Tue Apr 24 13:48:25 2012 +0200
+++ b/ChangeLog	Thu Apr 26 16:34:11 2012 +0200
@@ -1,3 +1,8 @@
+2012-04-26  Pavel Tisnovsky  <ptisnovs at redhat.com>
+
+	* src/org/gfxtest/testsuites/ClippingPathByRoundRectangleShape.java:
+	Added new tests to this test suite.
+
 2012-04-24  Pavel Tisnovsky  <ptisnovs at redhat.com>
 
 	* src/org/gfxtest/testsuites/PrintTestBasic.java:
diff -r 905b20725f80 -r 42228d31389e src/org/gfxtest/testsuites/ClippingPathByRoundRectangleShape.java
--- a/src/org/gfxtest/testsuites/ClippingPathByRoundRectangleShape.java	Tue Apr 24 13:48:25 2012 +0200
+++ b/src/org/gfxtest/testsuites/ClippingPathByRoundRectangleShape.java	Thu Apr 26 16:34:11 2012 +0200
@@ -74,6 +74,8 @@
 @Zoom(1)
 public class ClippingPathByRoundRectangleShape extends GfxTest
 {
+    private static final float[] DOTTED_PATTERN = new float[] {1,40};
+
     /**
      * Prepare canvas for the rendering.
      *
@@ -279,26 +281,6 @@
     }
 
     /**
-     * Check if crossed closed path could be clipped by a round rectangle shape.
-     * Path is rendered using stroke paint with default stroke width.
-     * 
-     * @param image
-     *            work image
-     * @param graphics2d
-     *            graphics canvas
-     * @return test result status - PASSED, FAILED or ERROR
-     */
-    public TestResult testClipCrossedClosedPathByRoundRectangleShapeStrokePaint(TestImage image, Graphics2D graphics2d)
-    {
-        // render clip round rectangle
-        CommonClippingOperations.renderClipRoundRectangle(image, graphics2d);
-        // set clip region and draw the path
-        drawCrossedClosedPathClippedByRoundRectangleShape(image, graphics2d);
-        // test result
-        return TestResult.PASSED;
-    }
-
-    /**
      * Check if line path could be clipped by a round rectangle shape. Path is
      * rendered using stroke paint with zero stroke width.
      * 
@@ -419,6 +401,246 @@
     }
 
     /**
+     * Check if line path could be clippRounded by a round rectangle shape. Path is rendered
+     * using stroke paint with thick stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipLinePathByRoundRectangleShapeThickStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render rectangle which is used as a clip shape
+        CommonClippingOperations.renderClipRoundRectangle(image, graphics2d);
+        // set stroke color
+        CommonRenderingStyles.setStrokeColor(graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeThickWidth(graphics2d);
+        // set clip region and draw the path
+        drawLinePathClippedByRoundRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if quadratic Bezier path could be clipped by a round rectangle shape. Path
+     * is rendered using stroke paint with thick stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipQuadraticPathByRoundRectangleShapeThickStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render rectangle which is used as a clip shape
+        CommonClippingOperations.renderClipRoundRectangle(image, graphics2d);
+        // set stroke color
+        CommonRenderingStyles.setStrokeColor(graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeThickWidth(graphics2d);
+        // set clip region and draw the path
+        drawQuadraticPathClippedByRoundRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if cubic Bezier path could be clipped by a round rectangle shape. Path
+     * is rendered using stroke paint with thick stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipCubicPathByRoundRectangleShapeThickStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render rectangle which is used as a clip shape
+        CommonClippingOperations.renderClipRoundRectangle(image, graphics2d);
+        // set stroke color
+        CommonRenderingStyles.setStrokeColor(graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeThickWidth(graphics2d);
+        // set clip region and draw the path
+        drawCubicPathClippedByRoundRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if closed path could be clipped by a round rectangle shape. Path
+     * is rendered using stroke paint with thick stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipClosedPathByRoundRectangleShapeThickStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render rectangle which is used as a clip shape
+        CommonClippingOperations.renderClipRoundRectangle(image, graphics2d);
+        // set stroke color
+        CommonRenderingStyles.setStrokeColor(graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeThickWidth(graphics2d);
+        // set clip region and draw the path
+        drawClosedPathClippedByRoundRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if crossed closed path could be clipped by a round rectangle shape. Path
+     * is rendered using stroke paint with thick stroke width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipCrossedClosedPathByRoundRectangleShapeThickStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render rectangle which is used as a clip shape
+        CommonClippingOperations.renderClipRoundRectangle(image, graphics2d);
+        // set stroke color
+        CommonRenderingStyles.setStrokeColor(graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeThickWidth(graphics2d);
+        // set clip region and draw the path
+        drawCrossedClosedPathClippedByRoundRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if line path could be clipped by a round rectangle shape. Path is rendered
+     * using stroke paint with extra thick width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipLinePathByRoundRectangleShapeExtraThickStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render rectangle which is used as a clip shape
+        CommonClippingOperations.renderClipRoundRectangle(image, graphics2d);
+        // set stroke color
+        CommonRenderingStyles.setStrokeColor(graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeExtraThickWidth(graphics2d);
+        // set clip region and draw the path
+        drawLinePathClippedByRoundRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if quadratic Bezier path could be clipped by a round rectangle shape. Path
+     * is rendered using stroke paint with extra thick width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipQuadraticPathByRoundRectangleShapeExtraThickStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render rectangle which is used as a clip shape
+        CommonClippingOperations.renderClipRoundRectangle(image, graphics2d);
+        // set stroke color
+        CommonRenderingStyles.setStrokeColor(graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeExtraThickWidth(graphics2d);
+        // set clip region and draw the path
+        drawQuadraticPathClippedByRoundRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if cubic Bezier path could be clipped by a round rectangle shape. Path
+     * is rendered using stroke paint with extra thick width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipCubicPathByRoundRectangleShapeExtraThickStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render rectangle which is used as a clip shape
+        CommonClippingOperations.renderClipRoundRectangle(image, graphics2d);
+        // set stroke color
+        CommonRenderingStyles.setStrokeColor(graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeExtraThickWidth(graphics2d);
+        // set clip region and draw the path
+        drawCubicPathClippedByRoundRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if closed path could be clipped by a round rectangle shape. Path
+     * is rendered using stroke paint with extra thick width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipClosedPathByRoundRectangleShapeExtraThickStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render rectangle which is used as a clip shape
+        CommonClippingOperations.renderClipRoundRectangle(image, graphics2d);
+        // set stroke color
+        CommonRenderingStyles.setStrokeColor(graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeExtraThickWidth(graphics2d);
+        // set clip region and draw the path
+        drawClosedPathClippedByRoundRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Check if crossed closed path could be clipped by a round rectangle shape. Path
+     * is rendered using stroke paint with extra thick width.
+     * 
+     * @param image
+     *            work image
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testClipCrossedClosedPathByRoundRectangleShapeExtraThickStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // render rectangle which is used as a clip shape
+        CommonClippingOperations.renderClipRoundRectangle(image, graphics2d);
+        // set stroke color
+        CommonRenderingStyles.setStrokeColor(graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeExtraThickWidth(graphics2d);
+        // set clip region and draw the path
+        drawCrossedClosedPathClippedByRoundRectangleShape(image, graphics2d);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
      * Entry point to the test suite.
      * 
      * @param args


From bugzilla-daemon at icedtea.classpath.org  Thu Apr 26 07:34:56 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Thu, 26 Apr 2012 14:34:56 +0000
Subject: [Bug 887] The bug for minecraft server on linux
In-Reply-To: <bug-887-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-887-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-887-30-CE4f16qKwi@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=887

--- Comment #5 from Xerxes R?nby <xerxes at zafena.se> ---
(In reply to comment #4)
> (In reply to comment #2)
> > Actually this bug migt have been fixed in hs21:
> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6840152
> 
> I don't see UseFastLocking or UseHeavyMonitors requested anywhere (I assume
> they're -XX options), so I don't think there's a connection to the latter
> bug id.

They are used by default so no extra options needs to get passed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120426/01bf53a2/attachment.html 

From bugzilla-daemon at icedtea.classpath.org  Thu Apr 26 08:30:39 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Thu, 26 Apr 2012 15:30:39 +0000
Subject: [Bug 887] The bug for minecraft server on linux
In-Reply-To: <bug-887-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-887-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-887-30-eZcHNzoUVE@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=887

--- Comment #6 from Stefan Ring <stefan at complang.tuwien.ac.at> ---
> Test if by adding -XX:-UseBiasedLocking would make your jvm to run more
> stable.

Alternatively, try -server. Almost all of the reports I can find about this
happen with the Client VM.

There's a good one with symbolic stack trace there:
http://www.minecraftforum.net/topic/1079165-server-123-crashes-with-exception/

VM_Operation is different, but might be related.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120426/69399a42/attachment.html 

From adinn at redhat.com  Thu Apr 26 09:20:38 2012
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 26 Apr 2012 17:20:38 +0100
Subject: ARM: Support for JVMTI notifications from JIT compiler on code
	generation
In-Reply-To: <4F97F2C5.1020802@redhat.com>
References: <4F97F2C5.1020802@redhat.com>
Message-ID: <4F9975D6.6020500@redhat.com>

Ok, here is the patch revised in the light of the previous feedback.
Both the patch /as was/ and /as is/ after this revision have been run on
a custom kernel tweaked so that oprofile operates correctly and are
generating coherent profile output. So, this can be considered to be tested.

One thing no one commented on was the use of the
JvmtiJavaThreadEventTransition marker and corresponding lack of any
HandleMark or other markers before calling out to the agent in the added
method JvmtiExport::post_compiled_method_load().

Anyone got anything to add on this or other aspects of the patch? Or can
I go ahead and commit this?

regards,


Andrew Dinn
-----------
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.txt
Url: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120426/2d7839a4/patch.txt 

From aph at redhat.com  Thu Apr 26 09:58:10 2012
From: aph at redhat.com (Andrew Haley)
Date: Thu, 26 Apr 2012 17:58:10 +0100
Subject: ARM: Support for JVMTI notifications from JIT compiler on code
	generation
In-Reply-To: <4F9975D6.6020500@redhat.com>
References: <4F97F2C5.1020802@redhat.com> <4F9975D6.6020500@redhat.com>
Message-ID: <4F997EA2.90108@redhat.com>

On 04/26/2012 05:20 PM, Andrew Dinn wrote:
> Anyone got anything to add on this or other aspects of the patch? Or can
> I go ahead and commit this?

One thing I can't see: you seem not to be checking to see if this
data is being collected by anyone.  If env->callbacks()->CompiledMethodLoad
is NULL, why are we doing all the work?

Andrew.



From bugzilla-daemon at icedtea.classpath.org  Thu Apr 26 10:36:36 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Thu, 26 Apr 2012 17:36:36 +0000
Subject: [Bug 886] 6-1.11.1 fails to build CACAO on ppc
In-Reply-To: <bug-886-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-886-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-886-30-GvhxmRUK4x@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=886

--- Comment #5 from Andrew John Hughes <ahughes at redhat.com> ---
We should consider backporting the fix to 1.11.  I've done that locally for
Gentoo, but not yet proposed it upstream.  Not had much focus on 6 recently.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120426/8d4e5b05/attachment.html 

From ptisnovs at redhat.com  Thu Apr 26 09:47:48 2012
From: ptisnovs at redhat.com (Pavel Tisnovsky)
Date: Thu, 26 Apr 2012 18:47:48 +0200
Subject: ARM: Support for JVMTI notifications from JIT compiler on code
	generation
In-Reply-To: <4F9975D6.6020500@redhat.com>
References: <4F97F2C5.1020802@redhat.com> <4F9975D6.6020500@redhat.com>
Message-ID: <4F997C34.1060203@redhat.com>

Andrew Dinn wrote:
> Ok, here is the patch revised in the light of the previous feedback.
> Both the patch /as was/ and /as is/ after this revision have been run on
> a custom kernel tweaked so that oprofile operates correctly and are
> generating coherent profile output. So, this can be considered to be tested.
> 
> One thing no one commented on was the use of the
> JvmtiJavaThreadEventTransition marker and corresponding lack of any
> HandleMark or other markers before calling out to the agent in the added
> method JvmtiExport::post_compiled_method_load().
> 
> Anyone got anything to add on this or other aspects of the patch? Or can
> I go ahead and commit this?
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> 

Looks ok,

I only saw two typos:

s/corrsponding/corresponding
s/thence/hence

And I have this question:

address_bci_map_add() - does not it need any check for address_bci_map_length value?
Are you sure it will newer be higher that THUMB2_MAX_BYTECODE_SIZE?

Cheers,
Pavel


From bugzilla-daemon at icedtea.classpath.org  Thu Apr 26 14:44:36 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Thu, 26 Apr 2012 21:44:36 +0000
Subject: [Bug 865] Patching fails with patches/ecj/jaxws-getdtdtype.patch
In-Reply-To: <bug-865-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-865-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-865-30-vAHBUDKS8G@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=865

Stefan Ring <stefan at complang.tuwien.ac.at> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #8 from Stefan Ring <stefan at complang.tuwien.ac.at> ---
http://icedtea.classpath.org/hg/icedtea6/rev/1b4551008907

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120426/f9329a2c/attachment.html 

From bugzilla-daemon at icedtea.classpath.org  Thu Apr 26 15:00:20 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Thu, 26 Apr 2012 22:00:20 +0000
Subject: [Bug 865] Patching fails with patches/ecj/jaxws-getdtdtype.patch
In-Reply-To: <bug-865-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-865-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-865-30-dP86ILiyKc@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=865

--- Comment #9 from Stefan Ring <stefan at complang.tuwien.ac.at> ---
Created attachment 683
  --> http://icedtea.classpath.org/bugzilla/attachment.cgi?id=683&action=edit
build log

I'm cleaning out my dropbox account, so I add the build log as an attachment
here.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120426/929f55d2/attachment.html 

From bugzilla-daemon at icedtea.classpath.org  Thu Apr 26 15:41:47 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Thu, 26 Apr 2012 22:41:47 +0000
Subject: [Bug 898] signed applications with big jnlp-file doesn't start
	(webstart affect like "frozen")
In-Reply-To: <bug-898-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-898-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-898-30-zQl303POKV@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=898

Omair Majid <omajid at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #2 from Omair Majid <omajid at redhat.com> ---
Closing as fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120426/b015ec51/attachment.html 

From bugzilla-daemon at icedtea.classpath.org  Thu Apr 26 15:42:48 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Thu, 26 Apr 2012 22:42:48 +0000
Subject: [Bug 918] java applet windows uses a low resulution black/white icon
In-Reply-To: <bug-918-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-918-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-918-30-vHunWgTykg@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=918

--- Comment #3 from Omair Majid <omajid at redhat.com> ---
Fixed in HEAD:
http://icedtea.classpath.org/hg/icedtea-web/rev/f13777a89e0d

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120426/7ded49e4/attachment.html 

From bugzilla-daemon at icedtea.classpath.org  Thu Apr 26 15:42:57 2012
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Thu, 26 Apr 2012 22:42:57 +0000
Subject: [Bug 918] java applet windows uses a low resulution black/white icon
In-Reply-To: <bug-918-30@http.icedtea.classpath.org/bugzilla/>
References: <bug-918-30@http.icedtea.classpath.org/bugzilla/>
Message-ID: <bug-918-30-rU2biHVhka@http.icedtea.classpath.org/bugzilla/>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=918

Omair Majid <omajid at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120426/ff715da5/attachment.html 

From adinn at redhat.com  Fri Apr 27 01:14:31 2012
From: adinn at redhat.com (Andrew Dinn)
Date: Fri, 27 Apr 2012 09:14:31 +0100
Subject: ARM: Support for JVMTI notifications from JIT compiler on code
	generation
In-Reply-To: <4F997C34.1060203@redhat.com>
References: <4F97F2C5.1020802@redhat.com> <4F9975D6.6020500@redhat.com>
	<4F997C34.1060203@redhat.com>
Message-ID: <4F9A5567.80300@redhat.com>

On 26/04/12 17:47, Pavel Tisnovsky wrote:
> Looks ok,
> 
> I only saw two typos:
> 
> s/corrsponding/corresponding
> s/thence/hence

thank you. I will correct the first mistake. However, 'thence' is
actually what I meant. It is like hence but means 'from there' rather
than 'from here'.

> And I have this question:
> 
> address_bci_map_add() - does not it need any check for address_bci_map_length value?
> Are you sure it will newer be higher that THUMB2_MAX_BYTECODE_SIZE?

The comment in the reset function which immediately precedes this is
meant to explain why checking is not required:

    // at worst we need a start address for every bytecode so
    // the map size is limited by the compiler's bytecode limit

Expanding that:

  the compiler will make at most one call to add for each bytecode

  it will not compile methods with more than THUMB2_MAX_BYTECODE_SIZE
bytecodes

  so add will never be called more than THUMB2_MAX_BYTECODE_SIZE times
for any given method

  so add can be called without checking the length if address_bci_map is
allocated with THUMB2_MAX_BYTECODE_SIZE entries.

I think this is clear if you read the code and the comment carefully.

regards,


Andrew Dinn
-----------


From adinn at redhat.com  Fri Apr 27 01:43:26 2012
From: adinn at redhat.com (Andrew Dinn)
Date: Fri, 27 Apr 2012 09:43:26 +0100
Subject: ARM: Support for JVMTI notifications from JIT compiler on code
	generation
In-Reply-To: <4F997EA2.90108@redhat.com>
References: <4F97F2C5.1020802@redhat.com> <4F9975D6.6020500@redhat.com>
	<4F997EA2.90108@redhat.com>
Message-ID: <4F9A5C2E.9040903@redhat.com>

On 26/04/12 17:58, Andrew Haley wrote:
> On 04/26/2012 05:20 PM, Andrew Dinn wrote:
> One thing I can't see: you seem not to be checking to see if this
> data is being collected by anyone.  If env->callbacks()->CompiledMethodLoad
> is NULL, why are we doing all the work?

Well, first thing, the compiler code does not know whether there are any
environments, never mind if they have enabled method load events or
supplied a non-null callback. My assumption in implementing the
jvmtiExport method was that access to the env list and specific env
configurations is -- conceptually, if not as regards access scope
declarations -- private to the jvmti classes. I will not that the other
compilers seem to make the same assumption -- the call they use (the one
which takes an nmethod argument) is made in all cases without any prior
check to see whether there is a client interested in the notification.
As a consequence they also generate the map data required for this call
in all cases (and indeed inlining data).

Secondly, envs may come and go at runtime and may have their state
modified. So, a check on the env list would need to be done before every
compile to record the current state then the code generator would need
to test this state before translating each bytecode in order to decide
whether to branch over the table write. Those costs needs to be offset
against the benefit from omitting the table writes. So it is not clear
to me that this pre-checking is a guaranteed win.

n.b. although the cost of the table writes increases with bytecode size
so also do the remaining generation costs so the marginal cost of
generating the profile data remains a fixed fraction of the total
compile cost.

So, it might be that having the compiler code peek through the
jvmtiExport API gives us a performance gain when no profiling is being
performed at the cost of breaking an abstraction barrier but I am not
convinced it will be significant. I could try to obtain some numbers to
prove this.

regards,


Andrew Dinn
-----------


From ptisnovs at icedtea.classpath.org  Fri Apr 27 03:58:59 2012
From: ptisnovs at icedtea.classpath.org (ptisnovs at icedtea.classpath.org)
Date: Fri, 27 Apr 2012 10:58:59 +0000
Subject: /hg/gfx-test: * src/org/gfxtest/framework/annotations/GraphicsPr...
Message-ID: <hg.95cf8a02f0dd.1335524339.-6248649288953172555@icedtea.classpath.org>

changeset 95cf8a02f0dd in /hg/gfx-test
details: http://icedtea.classpath.org/hg/gfx-test?cmd=changeset;node=95cf8a02f0dd
author: Pavel Tisnovsky <ptisnovs at redhat.com>
date: Fri Apr 27 13:01:29 2012 +0200

	* src/org/gfxtest/framework/annotations/GraphicsPrimitives.java:
	  Added new graphics primitive type.
	* src/org/gfxtest/testsuites/PrintTestCubicCurves.java:
	* src/org/gfxtest/testsuites/PrintTestLines.java:
	* src/org/gfxtest/testsuites/PrintTestPaths.java:
	* src/org/gfxtest/testsuites/PrintTestPolylines.java:
	* src/org/gfxtest/testsuites/PrintTestQuadraticCurves.java:
	  Stubs for new tests.
	* Makefile: Updated


diffstat:

 ChangeLog                                                     |  12 +
 Makefile                                                      |  14 +-
 src/org/gfxtest/framework/annotations/GraphicsPrimitives.java |   5 +
 src/org/gfxtest/testsuites/PrintTestCubicCurves.java          |  77 ++++++++++
 src/org/gfxtest/testsuites/PrintTestLines.java                |  78 ++++++++++
 src/org/gfxtest/testsuites/PrintTestPaths.java                |  79 ++++++++++
 src/org/gfxtest/testsuites/PrintTestPolylines.java            |  80 +++++++++++
 src/org/gfxtest/testsuites/PrintTestQuadraticCurves.java      |  78 ++++++++++
 8 files changed, 421 insertions(+), 2 deletions(-)

diffs (475 lines):

diff -r 42228d31389e -r 95cf8a02f0dd ChangeLog
--- a/ChangeLog	Thu Apr 26 16:34:11 2012 +0200
+++ b/ChangeLog	Fri Apr 27 13:01:29 2012 +0200
@@ -1,3 +1,15 @@
+2012-04-27  Pavel Tisnovsky  <ptisnovs at redhat.com>
+
+	* src/org/gfxtest/framework/annotations/GraphicsPrimitives.java:
+	Added new graphics primitive type.
+	* src/org/gfxtest/testsuites/PrintTestCubicCurves.java:
+	* src/org/gfxtest/testsuites/PrintTestLines.java:
+	* src/org/gfxtest/testsuites/PrintTestPaths.java:
+	* src/org/gfxtest/testsuites/PrintTestPolylines.java:
+	* src/org/gfxtest/testsuites/PrintTestQuadraticCurves.java:
+	Stubs for new tests.
+	* Makefile: Updated
+
 2012-04-26  Pavel Tisnovsky  <ptisnovs at redhat.com>
 
 	* src/org/gfxtest/testsuites/ClippingPathByRoundRectangleShape.java:
diff -r 42228d31389e -r 95cf8a02f0dd Makefile
--- a/Makefile	Thu Apr 26 16:34:11 2012 +0200
+++ b/Makefile	Fri Apr 27 13:01:29 2012 +0200
@@ -173,7 +173,12 @@
 	$(CLASSES)/$(TESTSUITE_DIR)/ClippingPathByConcavePolygonalShape.class \
 	$(CLASSES)/$(TESTSUITE_DIR)/ClippingPathBySelfIntersectingPolygonalShape.class \
 	$(CLASSES)/$(TESTSUITE_DIR)/ClippingPathByRoundRectangleShape.class \
-	$(CLASSES)/$(TESTSUITE_DIR)/PrintTestBasic.class
+	$(CLASSES)/$(TESTSUITE_DIR)/PrintTestBasic.class \
+	$(CLASSES)/$(TESTSUITE_DIR)/PrintTestCubicCurves.class \
+	$(CLASSES)/$(TESTSUITE_DIR)/PrintTestLines.class \
+	$(CLASSES)/$(TESTSUITE_DIR)/PrintTestPaths.class \
+	$(CLASSES)/$(TESTSUITE_DIR)/PrintTestPolylines.class \
+	$(CLASSES)/$(TESTSUITE_DIR)/PrintTestQuadraticCurves.class
 
 COMPARE_RESULTS = \
 	$(RESULTS)/Areas \
@@ -245,7 +250,12 @@
 	$(RESULTS)/ClippingPathBySelfIntersectingPolygonalShape \
 	$(RESULTS)/ClippingPathByRoundRectangleShape \
 	$(RESULTS)/ClippingPathByRectangleShape \
-	$(RESULTS)/PrintTestBasic
+	$(RESULTS)/PrintTestBasic \
+	$(RESULTS)/PrintTestCubicCurves \
+	$(RESULTS)/PrintTestLines \
+	$(RESULTS)/PrintTestPaths \
+	$(RESULTS)/PrintTestPolylines \
+	$(RESULTS)/PrintTestQuadraticCurves
 
 # targets for all test suites
 TESTSUITES = $(shell ls -1 src/org/gfxtest/testsuites | sed -n -e 's/\([A-Za-z0-9]*\)\.java/\1/p')
diff -r 42228d31389e -r 95cf8a02f0dd src/org/gfxtest/framework/annotations/GraphicsPrimitives.java
--- a/src/org/gfxtest/framework/annotations/GraphicsPrimitives.java	Thu Apr 26 16:34:11 2012 +0200
+++ b/src/org/gfxtest/framework/annotations/GraphicsPrimitives.java	Fri Apr 27 13:01:29 2012 +0200
@@ -121,4 +121,9 @@
      * Generic area, ie. closed shape.
      */
     AREA,
+
+    /**
+     * Text with various styles.
+     */
+    TEXT,
 }
diff -r 42228d31389e -r 95cf8a02f0dd src/org/gfxtest/testsuites/PrintTestCubicCurves.java
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/src/org/gfxtest/testsuites/PrintTestCubicCurves.java	Fri Apr 27 13:01:29 2012 +0200
@@ -0,0 +1,77 @@
+/*
+  Java gfx-test framework
+
+   Copyright (C) 2012  Red Hat
+
+This file is part of IcedTea.
+
+IcedTea is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+IcedTea is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with IcedTea; see the file COPYING.  If not, write to the
+Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+02110-1301 USA.
+
+Linking this library statically or dynamically with other modules is
+making a combined work based on this library.  Thus, the terms and
+conditions of the GNU General Public License cover the whole
+combination.
+
+As a special exception, the copyright holders of this library give you
+permission to link this library with independent modules to produce an
+executable, regardless of the license terms of these independent
+modules, and to copy and distribute the resulting executable under
+terms of your choice, provided that you also meet, for each linked
+independent module, the terms and conditions of the license of that
+module.  An independent module is a module which is not derived from
+or based on this library.  If you modify this library, you may extend
+this exception to your version of the library, but you are not
+obligated to do so.  If you do not wish to do so, delete this
+exception statement from your version.
+*/
+
+package org.gfxtest.testsuites;
+
+import org.gfxtest.framework.GfxTest;
+import org.gfxtest.framework.annotations.GraphicsPrimitive;
+import org.gfxtest.framework.annotations.GraphicsPrimitives;
+import org.gfxtest.framework.annotations.RenderStyle;
+import org.gfxtest.framework.annotations.RenderStyles;
+import org.gfxtest.framework.annotations.TestType;
+import org.gfxtest.framework.annotations.TestTypes;
+import org.gfxtest.framework.annotations.Transformation;
+import org.gfxtest.framework.annotations.Transformations;
+import org.gfxtest.framework.annotations.Zoom;
+
+/**
+ * This test suite checks rendering of various cubic curves.
+ * 
+ * @author Pavel Tisnovsky
+ */
+ at TestType(TestTypes.PRINT_TEST)
+ at GraphicsPrimitive(GraphicsPrimitives.CUBIC_CURVE)
+ at RenderStyle(RenderStyles.NORMAL)
+ at Transformation(Transformations.NONE)
+ at Zoom(1)
+public class PrintTestCubicCurves extends GfxTest
+{
+
+    /**
+     * Entry point to the test suite.
+     * 
+     * @param args
+     *            not used in this case
+     */
+    public static void main(String[] args)
+    {
+        new PrintTestCubicCurves().runTestSuite(args);
+    }
+}
diff -r 42228d31389e -r 95cf8a02f0dd src/org/gfxtest/testsuites/PrintTestLines.java
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/src/org/gfxtest/testsuites/PrintTestLines.java	Fri Apr 27 13:01:29 2012 +0200
@@ -0,0 +1,78 @@
+/*
+  Java gfx-test framework
+
+   Copyright (C) 2012  Red Hat
+
+This file is part of IcedTea.
+
+IcedTea is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+IcedTea is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with IcedTea; see the file COPYING.  If not, write to the
+Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+02110-1301 USA.
+
+Linking this library statically or dynamically with other modules is
+making a combined work based on this library.  Thus, the terms and
+conditions of the GNU General Public License cover the whole
+combination.
+
+As a special exception, the copyright holders of this library give you
+permission to link this library with independent modules to produce an
+executable, regardless of the license terms of these independent
+modules, and to copy and distribute the resulting executable under
+terms of your choice, provided that you also meet, for each linked
+independent module, the terms and conditions of the license of that
+module.  An independent module is a module which is not derived from
+or based on this library.  If you modify this library, you may extend
+this exception to your version of the library, but you are not
+obligated to do so.  If you do not wish to do so, delete this
+exception statement from your version.
+*/
+
+package org.gfxtest.testsuites;
+
+import org.gfxtest.framework.GfxTest;
+import org.gfxtest.framework.annotations.GraphicsPrimitive;
+import org.gfxtest.framework.annotations.GraphicsPrimitives;
+import org.gfxtest.framework.annotations.RenderStyle;
+import org.gfxtest.framework.annotations.RenderStyles;
+import org.gfxtest.framework.annotations.TestType;
+import org.gfxtest.framework.annotations.TestTypes;
+import org.gfxtest.framework.annotations.Transformation;
+import org.gfxtest.framework.annotations.Transformations;
+import org.gfxtest.framework.annotations.Zoom;
+
+
+
+/**
+ * This test suite checks rendering of various lines.
+ * 
+ * @author Pavel Tisnovsky
+ */
+ at TestType(TestTypes.PRINT_TEST)
+ at GraphicsPrimitive(GraphicsPrimitives.LINE)
+ at RenderStyle(RenderStyles.NORMAL)
+ at Transformation(Transformations.NONE)
+ at Zoom(1)
+public class PrintTestLines extends GfxTest
+{
+
+    /**
+     * Entry point to the test suite.
+     *
+     * @param args not used in this case
+     */
+    public static void main(String[] args)
+    {
+        new PrintTestLines().runTestSuite(args);
+    }
+}
diff -r 42228d31389e -r 95cf8a02f0dd src/org/gfxtest/testsuites/PrintTestPaths.java
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/src/org/gfxtest/testsuites/PrintTestPaths.java	Fri Apr 27 13:01:29 2012 +0200
@@ -0,0 +1,79 @@
+/*
+  Java gfx-test framework
+
+   Copyright (C) 2012  Red Hat
+
+This file is part of IcedTea.
+
+IcedTea is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+IcedTea is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with IcedTea; see the file COPYING.  If not, write to the
+Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+02110-1301 USA.
+
+Linking this library statically or dynamically with other modules is
+making a combined work based on this library.  Thus, the terms and
+conditions of the GNU General Public License cover the whole
+combination.
+
+As a special exception, the copyright holders of this library give you
+permission to link this library with independent modules to produce an
+executable, regardless of the license terms of these independent
+modules, and to copy and distribute the resulting executable under
+terms of your choice, provided that you also meet, for each linked
+independent module, the terms and conditions of the license of that
+module.  An independent module is a module which is not derived from
+or based on this library.  If you modify this library, you may extend
+this exception to your version of the library, but you are not
+obligated to do so.  If you do not wish to do so, delete this
+exception statement from your version.
+*/
+
+package org.gfxtest.testsuites;
+
+import org.gfxtest.framework.GfxTest;
+import org.gfxtest.framework.annotations.GraphicsPrimitive;
+import org.gfxtest.framework.annotations.GraphicsPrimitives;
+import org.gfxtest.framework.annotations.RenderStyle;
+import org.gfxtest.framework.annotations.RenderStyles;
+import org.gfxtest.framework.annotations.TestType;
+import org.gfxtest.framework.annotations.TestTypes;
+import org.gfxtest.framework.annotations.Transformation;
+import org.gfxtest.framework.annotations.Transformations;
+import org.gfxtest.framework.annotations.Zoom;
+
+
+
+/**
+ * This test suite checks rendering of various paths.
+ * 
+ * @author Pavel Tisnovsky
+ */
+ at TestType(TestTypes.PRINT_TEST)
+ at GraphicsPrimitive(GraphicsPrimitives.PATH)
+ at RenderStyle(RenderStyles.NORMAL)
+ at Transformation(Transformations.NONE)
+ at Zoom(1)
+public class PrintTestPaths extends GfxTest
+{
+    
+    /**
+     * Entry point to the test suite.
+     * 
+     * @param args
+     *            not used in this case
+     */
+    public static void main(String[] args)
+    {
+        new PrintTestPaths().runTestSuite(args);
+    }
+}
diff -r 42228d31389e -r 95cf8a02f0dd src/org/gfxtest/testsuites/PrintTestPolylines.java
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/src/org/gfxtest/testsuites/PrintTestPolylines.java	Fri Apr 27 13:01:29 2012 +0200
@@ -0,0 +1,80 @@
+/*
+  Java gfx-test framework
+
+   Copyright (C) 2012  Red Hat
+
+This file is part of IcedTea.
+
+IcedTea is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+IcedTea is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with IcedTea; see the file COPYING.  If not, write to the
+Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+02110-1301 USA.
+
+Linking this library statically or dynamically with other modules is
+making a combined work based on this library.  Thus, the terms and
+conditions of the GNU General Public License cover the whole
+combination.
+
+As a special exception, the copyright holders of this library give you
+permission to link this library with independent modules to produce an
+executable, regardless of the license terms of these independent
+modules, and to copy and distribute the resulting executable under
+terms of your choice, provided that you also meet, for each linked
+independent module, the terms and conditions of the license of that
+module.  An independent module is a module which is not derived from
+or based on this library.  If you modify this library, you may extend
+this exception to your version of the library, but you are not
+obligated to do so.  If you do not wish to do so, delete this
+exception statement from your version.
+*/
+
+package org.gfxtest.testsuites;
+
+import org.gfxtest.framework.GfxTest;
+import org.gfxtest.framework.annotations.GraphicsPrimitive;
+import org.gfxtest.framework.annotations.GraphicsPrimitives;
+import org.gfxtest.framework.annotations.RenderStyle;
+import org.gfxtest.framework.annotations.RenderStyles;
+import org.gfxtest.framework.annotations.TestType;
+import org.gfxtest.framework.annotations.TestTypes;
+import org.gfxtest.framework.annotations.Transformation;
+import org.gfxtest.framework.annotations.Transformations;
+import org.gfxtest.framework.annotations.Zoom;
+
+
+
+/**
+ * This test suite checks rendering of various polylines.
+ * 
+ * @author Pavel Tisnovsky
+ */
+ at TestType(TestTypes.PRINT_TEST)
+ at GraphicsPrimitive(GraphicsPrimitives.POLYLINE)
+ at RenderStyle(RenderStyles.NORMAL)
+ at Transformation(Transformations.NONE)
+ at Zoom(1)
+public class PrintTestPolylines extends GfxTest
+{
+    
+    /**
+     * Entry point to the test suite.
+     * 
+     * @param args
+     *            not used in this case
+     */
+    public static void main(String[] args)
+    {
+        new PrintTestPolylines().runTestSuite(args);
+    }
+    
+}
diff -r 42228d31389e -r 95cf8a02f0dd src/org/gfxtest/testsuites/PrintTestQuadraticCurves.java
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/src/org/gfxtest/testsuites/PrintTestQuadraticCurves.java	Fri Apr 27 13:01:29 2012 +0200
@@ -0,0 +1,78 @@
+/*
+  Java gfx-test framework
+
+   Copyright (C) 2012  Red Hat
+
+This file is part of IcedTea.
+
+IcedTea is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+IcedTea is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with IcedTea; see the file COPYING.  If not, write to the
+Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+02110-1301 USA.
+
+Linking this library statically or dynamically with other modules is
+making a combined work based on this library.  Thus, the terms and
+conditions of the GNU General Public License cover the whole
+combination.
+
+As a special exception, the copyright holders of this library give you
+permission to link this library with independent modules to produce an
+executable, regardless of the license terms of these independent
+modules, and to copy and distribute the resulting executable under
+terms of your choice, provided that you also meet, for each linked
+independent module, the terms and conditions of the license of that
+module.  An independent module is a module which is not derived from
+or based on this library.  If you modify this library, you may extend
+this exception to your version of the library, but you are not
+obligated to do so.  If you do not wish to do so, delete this
+exception statement from your version.
+*/
+package org.gfxtest.testsuites;
+
+import org.gfxtest.framework.GfxTest;
+import org.gfxtest.framework.annotations.GraphicsPrimitive;
+import org.gfxtest.framework.annotations.GraphicsPrimitives;
+import org.gfxtest.framework.annotations.RenderStyle;
+import org.gfxtest.framework.annotations.RenderStyles;
+import org.gfxtest.framework.annotations.TestType;
+import org.gfxtest.framework.annotations.TestTypes;
+import org.gfxtest.framework.annotations.Transformation;
+import org.gfxtest.framework.annotations.Transformations;
+import org.gfxtest.framework.annotations.Zoom;
+
+
+
+/**
+ * This test suite checks rendering of various quadratic curves.
+ * 
+ * @author Pavel Tisnovsky
+ */
+ at TestType(TestTypes.PRINT_TEST)
+ at GraphicsPrimitive(GraphicsPrimitives.QUADRATIC_CURVE)
+ at RenderStyle(RenderStyles.NORMAL)
+ at Transformation(Transformations.NONE)
+ at Zoom(1)
+public class PrintTestQuadraticCurves extends GfxTest
+{
+    
+    /**
+     * Entry point to the test suite.
+     * 
+     * @param args
+     *            not used in this case
+     */
+    public static void main(String[] args)
+    {
+        new PrintTestQuadraticCurves().runTestSuite(args);
+    }
+}


From jvanek at redhat.com  Fri Apr 27 04:30:14 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Fri, 27 Apr 2012 13:30:14 +0200
Subject: [rfc] [icedtea-web] providing little bit more debug outputs for few
	methods
Message-ID: <4F9A8346.6020808@redhat.com>

When I was looking to https://bugzilla.redhat.com/show_bug.cgi?id=816592 , I found few information 
missing in debug outputs (especially one consumed exception:-/)

This patch is adding this debug information, and I would like to push it to head and 1.2


Best regards, J.

changelog:
2012-04-27  Jiri Vanek  <jvanek at redhat.com>

	Added more debuging outputs
	* netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java: (getPermissions):
	Any exception from this method is consumed somewhere. I have catched exception,
	reprint it in debug mode and rethrow (to be lost). Main condition in this
	method had several possible NullPointer exceptions. Separated and thrown before
	this condition.
	(getCodeSourceSecurity): added output messsage when no SecurityDesc is found
	for some url/resource
	* netx/net/sourceforge/jnlp/security/KeyStores.java: (getPathToKeystore):
	new method, able to search for file used for creating of KeyStore if possible
	* netx/net/sourceforge/jnlp/security/CertificateUtils.java: (inKeyStores)
	using getPathToKeystore for debug output.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debuggingEnchancements.diff
Type: text/x-patch
Size: 4779 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120427/da938d44/debuggingEnchancements.diff 

From dbhole at redhat.com  Fri Apr 27 08:29:23 2012
From: dbhole at redhat.com (Deepak Bhole)
Date: Fri, 27 Apr 2012 11:29:23 -0400
Subject: [rfc] [icedtea-web] providing little bit more debug outputs for
	few methods
In-Reply-To: <4F9A8346.6020808@redhat.com>
References: <4F9A8346.6020808@redhat.com>
Message-ID: <20120427152923.GC3603@redhat.com>

* Jiri Vanek <jvanek at redhat.com> [2012-04-27 07:30]:
> When I was looking to
> https://bugzilla.redhat.com/show_bug.cgi?id=816592 , I found few
> information missing in debug outputs (especially one consumed
> exception:-/)
> 
> This patch is adding this debug information, and I would like to push it to head and 1.2
> 
> 

This patch is increasing verbosity and changing behavior (throwing a
different type of exception in getPermissions.

IMO it should be split..

Cheers,
Deepak

> Best regards, J.
> 
> changelog:
> 2012-04-27  Jiri Vanek  <jvanek at redhat.com>
> 
> 	Added more debuging outputs
> 	* netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java: (getPermissions):
> 	Any exception from this method is consumed somewhere. I have catched exception,
> 	reprint it in debug mode and rethrow (to be lost). Main condition in this
> 	method had several possible NullPointer exceptions. Separated and thrown before
> 	this condition.
> 	(getCodeSourceSecurity): added output messsage when no SecurityDesc is found
> 	for some url/resource
> 	* netx/net/sourceforge/jnlp/security/KeyStores.java: (getPathToKeystore):
> 	new method, able to search for file used for creating of KeyStore if possible
> 	* netx/net/sourceforge/jnlp/security/CertificateUtils.java: (inKeyStores)
> 	using getPathToKeystore for debug output.

> diff -r 82e908d46d70 netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java
> --- a/netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java	Tue Apr 24 14:43:34 2012 -0400
> +++ b/netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java	Fri Apr 27 13:10:49 2012 +0200
> @@ -895,6 +895,7 @@
>       * Returns the permissions for the CodeSource.
>       */
>      protected PermissionCollection getPermissions(CodeSource cs) {
> +        try{
>          Permissions result = new Permissions();
>  
>          // should check for extensions or boot, automatically give all
> @@ -912,6 +913,10 @@
>              // If more than default is needed:
>              // 1. Code must be signed
>              // 2. ALL or J2EE permissions must be requested (note: plugin requests ALL automatically)
> +            if (cs==null) throw new Exception("cs!=null but was");
> +            if (cs.getLocation()==null) throw new Exception("cs.getLocation!=null but was");
> +            if (getCodeSourceSecurity(cs.getLocation())==null) throw new Exception("getCodeSourceSecurity(cs.getLocation())!=null but was");
> +            if (getCodeSourceSecurity(cs.getLocation()).getSecurityType()==null) throw new Exception("getCodeSourceSecurity(cs.getLocation()).getSecurityType()!=null but was");
>              if (cs.getCodeSigners() != null &&
>                      (getCodeSourceSecurity(cs.getLocation()).getSecurityType().equals(SecurityDesc.ALL_PERMISSIONS) ||
>                       getCodeSourceSecurity(cs.getLocation()).getSecurityType().equals(SecurityDesc.J2EE_PERMISSIONS))) {
> @@ -933,6 +938,12 @@
>              result.add(runtimePermissions.get(i));
>  
>          return result;
> +         }catch(Exception ex){
> +                if (JNLPRuntime.isDebug()){
> +                ex.printStackTrace();
> +                }
> +                throw new Error(ex);
> +            }
>      }
>  
>      protected void addPermission(Permission p) {
> @@ -1732,7 +1743,12 @@
>       */
>  
>      protected SecurityDesc getCodeSourceSecurity(URL source) {
> -        return jarLocationSecurityMap.get(source);
> +        SecurityDesc sec=jarLocationSecurityMap.get(source);
> +        if (sec==null){
> +            System.out.println("Error! No security instance for signed "+source.toString()+" This source was loaded outside of netx, and application will have troubles to continue");
> +        }
> +        return sec;
> +
>      }
>  
>      /**
> diff -r 82e908d46d70 netx/net/sourceforge/jnlp/security/CertificateUtils.java
> --- a/netx/net/sourceforge/jnlp/security/CertificateUtils.java	Tue Apr 24 14:43:34 2012 -0400
> +++ b/netx/net/sourceforge/jnlp/security/CertificateUtils.java	Fri Apr 27 13:10:49 2012 +0200
> @@ -173,7 +173,7 @@
>  
>                      if (c.equals(keyStores[i].getCertificate(alias))) {
>                          if (JNLPRuntime.isDebug()) {
> -                            System.out.println(c.getSubjectX500Principal().getName() + " found in cacerts");
> +                            System.out.println(c.getSubjectX500Principal().getName() + " found in cacerts ("+KeyStores.getPathToKeystore(keyStores[i].hashCode())+")");
>                          }
>  
>                          return true;
> diff -r 82e908d46d70 netx/net/sourceforge/jnlp/security/KeyStores.java
> --- a/netx/net/sourceforge/jnlp/security/KeyStores.java	Tue Apr 24 14:43:34 2012 -0400
> +++ b/netx/net/sourceforge/jnlp/security/KeyStores.java	Fri Apr 27 13:10:49 2012 +0200
> @@ -47,7 +47,9 @@
>  import java.security.NoSuchAlgorithmException;
>  import java.security.cert.CertificateException;
>  import java.util.ArrayList;
> +import java.util.HashMap;
>  import java.util.List;
> +import java.util.Map;
>  import java.util.StringTokenizer;
>  
>  import net.sourceforge.jnlp.config.DeploymentConfiguration;
> @@ -75,6 +77,8 @@
>          CLIENT_CERTS,
>      }
>  
> +    public static final Map<Integer,String> keystoresPaths=new HashMap<Integer, String>();
> +
>      private static DeploymentConfiguration config = null;
>  
>      private static final String KEYSTORE_TYPE = "JKS";
> @@ -133,12 +137,23 @@
>          KeyStore ks = null;
>          try {
>              ks = createKeyStoreFromFile(new File(location), create, DEFAULT_PASSWORD);
> +            //hascode is used instead of instance so when no references are left
> +            //to keystore, then this will not be blocker for garbage collection
> +            keystoresPaths.put(ks.hashCode(),location);
>          } catch (Exception e) {
>              e.printStackTrace();
>          }
>          return ks;
>      }
>  
> +    public static String getPathToKeystore(int k) {
> +        String s = keystoresPaths.get(k);
> +        if (s == null) {
> +            return "unknown keystore location";
> +        }
> +        return s;
> +    }
> +
>      /**
>       * Returns an array of KeyStore that contain certificates that are trusted.
>       * The KeyStores contain certificates from different sources.



From jvanek at redhat.com  Mon Apr 30 05:13:15 2012
From: jvanek at redhat.com (Jiri Vanek)
Date: Mon, 30 Apr 2012 14:13:15 +0200
Subject: [rfc] [icedtea-web] providing little bit more debug outputs for
	few methods
In-Reply-To: <20120427152923.GC3603@redhat.com>
References: <4F9A8346.6020808@redhat.com> <20120427152923.GC3603@redhat.com>
Message-ID: <4F9E81DB.6050605@redhat.com>

On 04/27/2012 05:29 PM, Deepak Bhole wrote:
>
Thank you for review!
> This patch is increasing verbosity and changing behavior (throwing a
The verbosity is not increased so much:)
-one message in (3) when SecurityDesc is null
-one message in debug mode enriched  for one path (1)
-one stacktrace printed out in debug mode (is printed out (without debug) in  in-browser-applet already)

If you do not like any of this changesets just say, I do not insists on any of them. Thy just come 
to me handy (and in case of consumed exception correct)
> different type of exception in getPermissions.

arrrgggh. Thanx for catch. Fixed. Exception is  printed and truly re-thrown (not copy of it at it 
was:-/) now.
>
> IMO it should be split..
As you wish :)
>
Changelogs:
debuggingEnchancements2_1_pathToKeystores.diff

2012-04-30 Jiri Vanek  <jvanek at redhat.com>

	* netx/net/sourceforge/jnlp/security/KeyStores.java: (getPathToKeystore):
	new method, able to search for file used for creating of KeyStore if possible
	* netx/net/sourceforge/jnlp/security/CertificateUtils.java: (inKeyStores)
	using getPathToKeystore for debug output.

debuggingEnchancements2_2_consumedExceptionPrintOut.diff

2012-04-30  Jiri Vanek  <jvanek at redhat.com>

	* netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java: (getPermissions):
	Any exception from this method is consumed somewhere. I have cough exception,
	reprint it in debug mode and re-throw (to be lost). Main condition in this
	method had several possible NullPointer exceptions. Separated and thrown before
	this condition.
	

debuggingEnchancements2_3_printOutMissingSecurityDesc.diff

2012-04-30  Jiri Vanek  <jvanek at redhat.com>

	Added more debuging outputs
	* netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java:
	(getCodeSourceSecurity): added output message when no SecurityDesc is found
	for some url/resource
	

Best regards, J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debuggingEnchancements2_3_printOutMissingSecurityDesc.diff
Type: text/x-patch
Size: 733 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120430/dfad8229/debuggingEnchancements2_3_printOutMissingSecurityDesc.diff 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debuggingEnchancements2_2_consumedExceptionPrintOut.diff
Type: text/x-patch
Size: 1899 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120430/dfad8229/debuggingEnchancements2_2_consumedExceptionPrintOut.diff 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debuggingEnchancements2_1_pathToKeystores.diff
Type: text/x-patch
Size: 2431 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120430/dfad8229/debuggingEnchancements2_1_pathToKeystores.diff 

From ptisnovs at redhat.com  Mon Apr 30 05:36:14 2012
From: ptisnovs at redhat.com (Pavel Tisnovsky)
Date: Mon, 30 Apr 2012 08:36:14 -0400 (EDT)
Subject: [rfc][icedtea-web] Bug annotation
In-Reply-To: <4F98124B.5050705@redhat.com>
Message-ID: <112051b8-857c-4067-abf9-64da86b8d725@zmail14.collab.prod.int.phx2.redhat.com>

Hi Jiri,

I think it's a good idea to use @Bug annotation and I'm ok with use it in a generated HTML report.

Pavel


----- Jiri Vanek <jvanek at redhat.com> wrote:
> Hi all!
> 4/5 of  browser testing framework. This one is not related to testing of applets in browsers, but is 
> extension to testing framework as a complex. I got inspired by jtreg and by Pavel and our 
> documentaries  who are always annoyed when tracking some bug in icedtea-web.
> 
> This was originally purposed by me in  Extending jnlp reproducers for html+applet reproducers in 
> March [1]:
> 
> *@Bug* annotation  - can handle IDs of bugs or urls to web which contains more info about "why this
> reproducer or unit test was added", are *nicely* propagated also to html report (see attached
> report.zip). Name convention is as we are used to from NEWS files."
> 
> 
> [1] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-March/017799.html
> 
> 
> Best regars
> J.
> 
> changelog
> 
> 2012-04-25  Jiri Vanek  <jvanek at redhat.com>
> 
> 	Introduced new annotations Bug (to connect test/reproducer with documentation) and NeedsDisplay 
> which tells the launching engine that this particular test needs Display. Based on ptisnovs's ideas 
> and jtreg experiences
> 	*Makefile.am: (JUNIT_RUNNER_JAR), (stamps/run-netx-unit-tests.stamp) and
> (stamps/run-unit-test-code-coverage.stamp) are now dependent on (stamps/netx-dist-tests-compile) and 
> classpaths inside them have been enriched for JNLP_TESTS_ENGINE_DIRwhich contains definitions of 
> those annotations
> 	*tests/jnlp_tests/simple/CheckServices/testcases/CheckServicesTests.java: and
> 	*tests/jnlp_tests/simple/ManifestedJar1/testcases/ManifestedJar1Test.java: and
> 	*tests/jnlp_tests/simple/Spaces can be everywhere/testcase/SpacesCanBeEverywhereTests.java: filled 
> Bug annotations
> 	*tests/junit-runner/JunitLikeXmlOutputListener.java: made to understand Bug annotation
> 	*tests/netx/jnlp_testsengine/net/sourceforge/jnlp/annotations/NeedsDisplay.java: and
> 	*tests/netx/jnlp_testsengine/net/sourceforge/jnlp/annotations/Bug.java: annotations definitions
> 	*tests/report-styles/jreport.xsl" made nice links from bug annotation prepared by
> JunitLikeXmlOutputListener
> 



From thomas at m3y3r.de  Mon Apr 30 04:11:07 2012
From: thomas at m3y3r.de (Thomas Meyer)
Date: Mon, 30 Apr 2012 13:11:07 +0200
Subject: RFC - Reduce loading of PropertiesFile
In-Reply-To: <4F91398F.5080801@redhat.com>
References: <1334087640.1431.26.camel@localhost.localdomain>
	<4F86D475.5020202@redhat.com>
	<1334520186.1444.43.camel@localhost.localdomain>
	<4F8C1644.5090001@redhat.com>
	<1334862860.1435.15.camel@localhost.localdomain>
	<4F91398F.5080801@redhat.com>
Message-ID: <1335784267.1363.30.camel@localhost.localdomain>

Am Freitag, den 20.04.2012, 12:25 +0200 schrieb Jiri Vanek:
> On 04/19/2012 09:14 PM, Thomas Meyer wrote:
> > Am Montag, den 16.04.2012, 14:53 +0200 schrieb Jiri Vanek:
> >
> >>>> Also I would like to suggest at least two tests with this patch
> >>>> 1) generate eg 1mb recently_used file and measure set some deadline how fast javaws  have to start.
> >>>>      The value should be failing without this patch, and  passing with this one applied. Also some
> >>>> real number how faster this is will be much appreciate!
> >
> > Hi,
> >
> > Attached are two patches that implement a unit test of
> > CacheLRUWrapper.load()
> >
> > Some numbers of my previous optimisation patches:
> >
> > No. of entries in the recently_used file = 1000
> > No. of calls to CacheLRUWrapper.load() = 1000
> >
> > Before: Average = 3802485.0 ns
> > After:  Average = 44887.0 ns
> >
> >>>>
> >>>> 2) second one will be little bit more difficult. It would be nice to test, that when recently_used
> >>>> is modified during javaws run, then it reloads it correctly. And so verify that this patch will not
> >>>> cause some regression.
> >
> > Still on my todo list :-)
> >
> >>>> Maybe unittest will be easier to prepare instead of 2)
> >>>> But I'm afraid those (or similar ) tests will be really necessary.
> >>>
> >
> >
> >>   >  diff -r 17f9e4e1ac6d netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java
> >> --- a/netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java	Wed Apr 11 10:19:17 2012 +0200
> >> +++ b/netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java	Mon Apr 16 14:08:18 2012 +0200
> >> @@ -108,11 +108,11 @@
> >>         * Update map for keeping track of recently used items.
> >>         */
> >>        public synchronized void load() {
> >> -        cacheOrder.load();
> >> +        boolean loaded = cacheOrder.load();
> >>            /*
> >>             * clean up possibly corrupted entries
> >>             */
> >> -        if (checkData()) {
> >> +        if (loaded == true&&  checkData()) {
> >>
> >>   >  As already told above, Unless there is some particular reason, please avoid boolean comparsion with true/false
> >
> > this is actually fixed in this patch. the attached patch file consists
> > actually of two diffs that needs to be applied to the icedtea-web repo
> > in order. mercurial doesn't let me rewrite the commit history, so I just
> > exported all revisions in one file. that's actually a bit confusing,
> > when you only look at the patch file.
> >
> >
> >>
> >>                if (JNLPRuntime.isDebug()) {
> >>                    new LruCacheException().printStackTrace();
> >>                }
> >> @@ -125,7 +125,7 @@
> >>        /**
> >>         * check content of cacheOrder and remove invalid/corrupt entries
> >>         *
> >> -     * @return true, if cache was coruupted and affected entry removed
> >> +     * @return true, if cache was corrupted and affected entry removed
> >>         */
> >>        private boolean checkData () {
> >>            boolean modified = false;
> >> diff -r 17f9e4e1ac6d netx/net/sourceforge/jnlp/util/PropertiesFile.java
> >> --- a/netx/net/sourceforge/jnlp/util/PropertiesFile.java	Wed Apr 11 10:19:17 2012 +0200
> >> +++ b/netx/net/sourceforge/jnlp/util/PropertiesFile.java	Mon Apr 16 14:08:18 2012 +0200
> >> @@ -104,24 +107,38 @@
> >>         * Ensures that the file backing these properties has been
> >>         * loaded; call this method before calling any method defined by
> >>         * a superclass.
> >> +     *
> >> +     * @return true, if file was (re-)loaded
> >> +     *         false, if file was still current
> >>         */
> >> -    public void load() {
> >> +    public boolean load() {
> >> +
> >> +        if (!file.exists())
> >> +            return false;
> >>
> >>   >  this is really nitpick and I'm sorry for it, but current code guidelines dictate brackets after if
> >
> > okay, will fix this, too.
> >
> >> @@ -131,12 +148,16 @@
> >>            if (!loaded)
> >>                return; // nothing could have changed so save unnecessary load/save
> >>
> >> -        OutputStream s = null;
> >> +        FileOutputStream s = null;
> >>            try {
> >>                try {
> >>                    file.getParentFile().mkdirs();
> >>                    s = new FileOutputStream(file);
> >>                    store(s, header);
> >> +
> >> +                // fsync()
> >> +                s.getChannel().force(true);
> >> +                lastStore = file.lastModified();
> >>   >  Very well :) I have never seen this before, so I hope you know what you are doing:) (but looks correct from javadoc)
> >
> > I'm not sure if a flush() is needed before the fsync() aka.
> > s.getChannel().force(true);
> > Internet suggest a flush() is needed. I may add this. Suggestions?
> >
> 
> Only naive one - flush() fill certainly not make thinks worse. So I'm for.

flush() is not needed and is already done in the Properties.store()
method.

> 
> Nice work till now! Let's wait for last test and looking forward for push!

All-in-one-patch attached. What do you think about this?

with kind regards
thomas


-------------- next part --------------
A non-text attachment was scrubbed...
Name: reduce-load-and-unit-test.patch
Type: text/x-patch
Size: 16821 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120430/5f2fd439/reduce-load-and-unit-test.patch 

From thomas at m3y3r.de  Mon Apr 30 02:26:29 2012
From: thomas at m3y3r.de (Thomas Meyer)
Date: Mon, 30 Apr 2012 11:26:29 +0200
Subject: [RFC] [openjdk] provide milisecond modification timestamps
In-Reply-To: <21902c50-a21f-4605-b82c-3ed494fa1c9a@zmail17.collab.prod.int.phx2.redhat.com>
References: <21902c50-a21f-4605-b82c-3ed494fa1c9a@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <1335777989.1363.22.camel@localhost.localdomain>

Am Dienstag, den 24.04.2012, 20:39 -0400 schrieb Andrew Hughes:
> ----- Original Message -----
> > Am Montag, den 23.04.2012, 14:22 -0400 schrieb Andrew Hughes:
> > > ----- Original Message -----
> > > > Am Montag, den 23.04.2012, 12:41 -0400 schrieb Andrew Hughes:
> > > > > ----- Original Message -----
> > > > > > diff -r 8ac52c85f9e9
> > > > > > src/solaris/native/java/io/UnixFileSystem_md.c
> > > > > > --- a/src/solaris/native/java/io/UnixFileSystem_md.c	Wed Feb
> > > > > > 23
> > > > > > 15:49:19
> > > > > > 2011 -0800
> > > > > > +++ b/src/solaris/native/java/io/UnixFileSystem_md.c	Sat Apr
> > > > > > 21
> > > > > > 10:11:26
> > > > > > 2012 +0200
> > > > > > @@ -197,7 +197,10 @@
> > > > > >      WITH_FIELD_PLATFORM_STRING(env, file, ids.path, path) {
> > > > > >          struct stat64 sb;
> > > > > >          if (stat64(path, &sb) == 0) {
> > > > > > -            rv = 1000 * (jlong)sb.st_mtime;
> > > > > > +            if(sb.st_mtimensec != 0)
> > > > > > +            	rv = (jlong)sb.st_mtimensec / 1000000;
> > > > > > +            else
> > > > > > +                rv = 1000 * (jlong)sb.st_mtime;
> > > > > >          }
> > > > > >      } END_PLATFORM_STRING(env, path);
> > > > > >      return rv;
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > > Hi Andrew,
> > > > 
> > > > > This looks a sensible improvement to me.  I can add it to the
> > > > > IcedTea
> > > > > repository.
> > > > 
> > > > But it only looks sensible :-) The correct patch against jdk7 is
> > > > attached!
> > > > 
> > > > I looks like the field st_mtim.tv_nsec is just an extension to
> > > > the
> > > > second accuracy provided by st_mtim.tv_sec.
> > > > 
> > > 
> > > Ah right, yes this is the same way clock_gettime works, which we
> > > use
> > > to implement System.nanoTime in GNU Classpath:
> > > 
> > >   result = (jlong) tp.tv_sec;
> > >   result *= (jlong)1000000000L;
> > >   result += (jlong)tp.tv_nsec;
> > > 
> > > The difference here is that the Java API means that most of the
> > > accuracy
> > > gain is lost in the division.  I wonder if there is a case for a
> > > deeper
> > > patch that allows nanosecond accuracy to be fully exposed?
> > 
> > At least not for File.lastModified() which returns "a long value
> > representing the time the file was last modified, measured in
> > milliseconds since the epoch".
> > 
> 
> Yes, I guessed that.  But it doesn't mean another method couldn't be added.
> But...
> 
> > [me having a quick look at the new stuff in 1.7]
> > 
> > Oh, nice! Java 7 seems to have FileTime and
> > Files.getLastModifiedTime().
> > 
> 
> ...I'm guessing Oracle will just point to this new API.  Does it provide
> nanosecond accuracy?

The API looks like it could support nanosecond timestamps (because of
the abstraction via FileTime class), but surprisingly it doesn't support
it!

[jdk7]$ grep -R st_mtim *
hotspot/src/share/vm/memory/filemap.cpp:      _header._jar[_header._num_jars]._timestamp = st.st_mtime;
hotspot/src/share/vm/memory/filemap.cpp:        if (_header._jar[num_jars_now]._timestamp != st.st_mtime ||
hotspot/src/os/windows/vm/os_windows.cpp:    // Fix for 6539723.  st_mtime returned from stat() is dependent on
hotspot/src/os/windows/vm/os_windows.cpp:    sbuf->st_mtime += (tz.Bias + daylightBias) * 60;
-> Hotspot stuff

jdk/src/solaris/native/java/io/UnixFileSystem_md.c:            rv = 1000 * (jlong)sb.st_mtim.tv_sec + (jlong)sb.st_mtim.tv_nsec / 1000000;
-> My patch applied. unix syscall happens here for old File.lastModified()

jdk/src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c:static jfieldID attrs_st_mtime;
jdk/src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c:    attrs_st_mtime = (*env)->GetFieldID(env, clazz, "st_mtime", "J");
jdk/src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c:    (*env)->SetLongField(env, attrs, attrs_st_mtime, (jlong)buf->st_mtime);
jdk/src/solaris/classes/sun/nio/fs/UnixFileAttributes.java:    private long    st_mtime;
jdk/src/solaris/classes/sun/nio/fs/UnixFileAttributes.java:        return FileTime.from(st_mtime, TimeUnit.SECONDS);
-> New Java 1.7 API stuff


The read of the st_mtim for File.lastModified() seems to happen in the
file I patched:
 jdk/src/solaris/native/java/io/UnixFileSystem_md.c

The new 1.7 API seems to always return FileTime in units "SECONDS", see:
 jdk/src/solaris/classes/sun/nio/fs/UnixFileAttributes.java

and the read (stat64 syscall) happens here:
 jdk/src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c
 jdk/src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java
-> only st_mtime is used! So no nanosecond accuracy for the new API... 

> 
> > But I guess the 1.7 API is no option for icedtea-web (yet)?!
> > 
> 
> I don't see why IcedTea-Web is relevant to this discussion?

I'm about to implement a check in icedtea-web to not reload the cache
index file when the file modification timestamp has not changed since
the last save of the file. I stumbled upon this while trying to write
some unit tests to check if the file needs to be reloaded resp. has been
reloaded. Given that my underlying ext4 file system support nanosecond
resolution I did wonder why my check for the modification timestamp did
not work, i.e. the file was not reloaded as expected.

with kind regards
thomas





From omajid at redhat.com  Mon Apr 30 11:19:06 2012
From: omajid at redhat.com (Omair Majid)
Date: Mon, 30 Apr 2012 14:19:06 -0400
Subject: [rfc][icedtea-web] Bug annotation
In-Reply-To: <4F98124B.5050705@redhat.com>
References: <4F98124B.5050705@redhat.com>
Message-ID: <4F9ED79A.50300@redhat.com>

On 04/25/2012 11:03 AM, Jiri Vanek wrote:
> Hi all!
> 4/5 of  browser testing framework. This one is not related to testing of
> applets in browsers, but is extension to testing framework as a complex.
> I got inspired by jtreg and by Pavel and our documentaries  who are
> always annoyed when tracking some bug in icedtea-web.
> 
> This was originally purposed by me in  Extending jnlp reproducers for
> html+applet reproducers in March [1]:
> 
> *@Bug* annotation  - can handle IDs of bugs or urls to web which
> contains more info about "why this
> reproducer or unit test was added", are *nicely* propagated also to html
> report (see attached
> report.zip). Name convention is as we are used to from NEWS files."

Just a suggestion for possible improvement. Perhaps it would be nice to
separate the bug ids from discussion threads. How about something like
this instead:

@Bug(ids={"PR42"},discussion={"http://some/url/to/discussion"}) ?

Cheers,
Omair