Mijn Dealingroom

bufferString

+ *      byte    mydata[];
+ *      BASE64Decoder base64 = new BASE64Decoder();
+ *
+ *      mydata = base64.decodeBuffer(bufferString);
+ * 
+ *    "BASE64Decoder: Not enough bytes for an atom."
+ * 
+ *      [Buffer Prefix]
+ *      [Line Prefix][encoded data atoms][Line Suffix]
+ *      [Buffer Suffix]
+ * 
+ *      DecoderClassName: Error message.
+ * 
\nfor({0} c: {0}.values())\n  System.out.println(c);\n
\nfor({0} c: {0}.values())\n  System.out.println(c);\n
\nfor ({0} c : {0}.values())\n    System.out.println(c);\n

   * FirefoxPreferencesParser p = new FirefoxPreferencesParser(prefsFile);
   * p.parse();
   * Map<String,String> prefs = p.getPreferences();
   * System.out.println("blink allowed: " + prefs.get("browser.blink_allowed"));
- * 

>    * FirefoxPreferencesParser p = new FirefoxPreferencesParser(prefsFile);
>    * p.parse();
>    * Map<String,String> prefs = p.getPreferences();
>    * System.out.println("blink allowed: " + prefs.get("browser.blink_allowed"));
> - * 
 is just a styling element, giving a hint as how to render enclosed 
content.  is a meta element meaning that the enclosed content is 
considered some sort of code that could serve as input to some parsers or 
compiles etc.  does not carry any notion about rendering.

>   /**
> - *
> - * @author jvanek
> + * @author Jiri
> Vanek
>    */
>
> Ugh. Author tag is not allowed. Please just remove instead of fix.

Why is that? A lot of classes have @author doctags. It does not denote 
ownership. It is just a hint as to whom to turn for questions about the code in 
the future.
If they are absolutely not allowed, well then all other existing @author doctags 
need to be stripped too. And, that's kind of mind boggling.

> diff -r efa527f74184
> netx/net/sourceforge/jnlp/util/logging/ConsoleOutputPaneModel.java
> --- a/netx/net/sourceforge/jnlp/util/logging/ConsoleOutputPaneModel.java
> +++ b/netx/net/sourceforge/jnlp/util/logging/ConsoleOutputPaneModel.java
> @@ -188,8 +188,8 @@
>               }
>               String line = (createLine(messageWithHeader));
>               if (mark) {
> -                line = line.replaceAll("\n", "
\n");
> -                line = line.replaceAll("  ", "  ");//small trick, html is
> reducting row of sapces to single space. This handles it and stimm allow line wrap
> +                line = line.replaceAll("\n", "
\n");
> +                line = line.replaceAll("  ", "  ");//small trick, html is
> reducting row of spaces to single space. This handles it and stimm allow line wrap
>                   line = line.replaceAll("\t", "    ");
>
> This is not possible. Unluckily the java html parser do not survive 
.
> Please remove this hunk.

That's a drag. :-\ It should definitely accept it. I guess the same applies to 
some message properties?

> After fixing above. Looks ok.
>
>
> Is backport to 1.4 possible? As the cnages are 99% really javadoc related, I do
> not insists. My motivation  to backport have only one  valaid point - The
> refactoring is changing  backporting and forwardporting  from automatic level to
> manual one.  Unless you have something against, do you mind to backport valid
> parts after  1.4.2 release?

I do know for sure because there is a lot of stuff here that is not in 1.4. But, 
I will take a look at it.

Jacob


From gitne at gmx.de  Mon Jan 27 11:17:03 2014
From: gitne at gmx.de (Jacob Wisor)
Date: Mon, 27 Jan 2014 20:17:03 +0100
Subject: /hg/icedtea-web: Improve PolicyTool launch method in PolicyPanel
In-Reply-To: <52E66F94.9010901@redhat.com>
References: 
	<52E2991C.1020606@gmx.de> <52E66F94.9010901@redhat.com>
Message-ID: <52E6B0AF.5050805@gmx.de>

On 01/27/2014 03:39 PM, Jiri Vanek wrote:
> ...
>>> +     * @param filePath a {@link String} representing the path of the file to
>>> attempt to open
>>> +     * @throws Exception if any sort of exception occurs during reflective
>>> launch of policytool
>>> +     */
>>> +    private static void reflectivePolicyToolLaunch(final String filePath)
>>> throws Exception {
>>> +        Class policyTool =
>>> Class.forName("sun.security.tools.policytool.PolicyTool");
>>
>> What about JRE 6? You could catch a ClassNotFoundException here and then try
>> to get
>> sun.security.tools.PolicyTool. And, if that fails, well then... Blow up! :-D
>
> Well - why yes? The jdk6 is dead. We are dealing with slowly, but its true. The
> command exec is what matters. The second one is fallback.
>
> If you have non-policytool command, non jdk7 system. Please go on and fix.
> Otherwise I do not believe it is worthy.

The reason I mentioned this is because as Andrew wants to backport this patch to 
1.4 and many machines will probably still be running on a strict combination of 
IcedTea-Web 1.4 on JRE 6 (for various reasons), the fallback for the *new 
feature* introduced by it will not work on this combination. Your proposed quick 
"fix" is not always easily possible, eg. because some other major software 
requires JRE 6 to run. This is also one reason why I called this patch a *new 
feature* and am against backporting it. But, if the patch is going to be 
backported then please also make sure that IcedTea-Web 1.4 will run on JREs that 
were still in wide use during its initial release, like JRE 6. Yes, even when 
resorting to a fallback.

As a side note: Those version numbers have a meaning indeed. They are not just 
some sort of fancy way for naming things. They define feature sets and 
dependencies. This is especially important for business people.

> And if we will nit pick -what about gnu classpath ? ;)

Classpath or any other JRE do not apply as an argument here because we always 
assumed that this a OpenJDK/Oracle JRE specific feature. J2SE leaves it up to 
the JRE vendor on how to implement the configuration of the default 
SecurityManager and default Permissions.

Jacob

From aazores at redhat.com  Mon Jan 27 11:32:32 2014
From: aazores at redhat.com (Andrew Azores)
Date: Mon, 27 Jan 2014 14:32:32 -0500
Subject: /hg/icedtea-web: Improve PolicyTool launch method in PolicyPanel
In-Reply-To: <52E6B0AF.5050805@gmx.de>
References: 
	<52E2991C.1020606@gmx.de> <52E66F94.9010901@redhat.com>
	<52E6B0AF.5050805@gmx.de>
Message-ID: <52E6B450.2050500@redhat.com>

On 01/27/2014 02:17 PM, Jacob Wisor wrote:
> On 01/27/2014 03:39 PM, Jiri Vanek wrote:
>> ...
>>>> +     * @param filePath a {@link String} representing the path of 
>>>> the file to
>>>> attempt to open
>>>> +     * @throws Exception if any sort of exception occurs during 
>>>> reflective
>>>> launch of policytool
>>>> +     */
>>>> +    private static void reflectivePolicyToolLaunch(final String 
>>>> filePath)
>>>> throws Exception {
>>>> +        Class policyTool =
>>>> Class.forName("sun.security.tools.policytool.PolicyTool");
>>>
>>> What about JRE 6? You could catch a ClassNotFoundException here and 
>>> then try
>>> to get
>>> sun.security.tools.PolicyTool. And, if that fails, well then... Blow 
>>> up! :-D
>>
>> Well - why yes? The jdk6 is dead. We are dealing with slowly, but its 
>> true. The
>> command exec is what matters. The second one is fallback.
>>
>> If you have non-policytool command, non jdk7 system. Please go on and 
>> fix.
>> Otherwise I do not believe it is worthy.
>
> The reason I mentioned this is because as Andrew wants to backport 
> this patch to 1.4

I'm sorry - what? Please go back and re-read the mail from three days 
ago where I posted the backport patch.

> and many machines will probably still be running on a strict 
> combination of IcedTea-Web 1.4 on JRE 6 (for various reasons), the 
> fallback for the *new feature* introduced by it will not work on this 
> combination. Your proposed quick "fix" is not always easily possible, 
> eg. because some other major software requires JRE 6 to run. This is 
> also one reason why I called this patch a *new feature* and am against 
> backporting it. But, if the patch is going to be backported then 
> please also make sure that IcedTea-Web 1.4 will run on JREs that were 
> still in wide use during its initial release, like JRE 6. Yes, even 
> when resorting to a fallback.
>
> As a side note: Those version numbers have a meaning indeed. They are 
> not just some sort of fancy way for naming things. They define feature 
> sets and dependencies. This is especially important for business people.

Anyway. If this patch is going to get backported to 1.4 then I think 
you're right and 6-compatibility should be taken into account (ie 
reflective fallback should also check for PolicyTool in its old 
package). I'm not sure how much we care about this for the 1.5 patch, 
but perhaps it would still be worth adding. I doubt there are very many 
users who are going to be using ITW 1.5 alongside Java 6, and of those 
users, how many are going to be trying to launch PolicyTool from the 
PolicyPanel *and* relying on the fallback reflective launch? To me this 
sounds like very very few users if any. But, it also isn't really too 
much more work, it will just make the PolicyPanel messier with all the 
extra reflective fallback cruft. If it's already being done for 1.4 then 
it might as well get done for 1.5, however.

>
>> And if we will nit pick -what about gnu classpath ? ;)
>
> Classpath or any other JRE do not apply as an argument here because we 
> always assumed that this a OpenJDK/Oracle JRE specific feature. J2SE 
> leaves it up to the JRE vendor on how to implement the configuration 
> of the default SecurityManager and default Permissions.
>
> Jacob

Thanks,

-- 
Andrew A


From aazores at redhat.com  Mon Jan 27 11:54:05 2014
From: aazores at redhat.com (Andrew Azores)
Date: Mon, 27 Jan 2014 14:54:05 -0500
Subject: [rfc][icedtea-web] External main-class fix
In-Reply-To: <52D5903C.6010404@redhat.com>
References: <52CDC9BA.4000406@redhat.com> <52D5903C.6010404@redhat.com>
Message-ID: <52E6B95D.4090004@redhat.com>

On 01/14/2014 02:30 PM, Andrew Azores wrote:
> On 01/08/2014 04:57 PM, Andrew Azores wrote:
>> Hi,
>>
>> Jiri found a flaw in the fix for PR1513, which allows applets to run 
>> when their main-class is not in a JAR, but is still available to load 
>> from the codebase. The previous fix simply didn't throw a 
>> LaunchException when the main-class could not be found in a JAR, and 
>> instead displayed a warning about not all of the code being signed. 
>> However, this warning could still appear even if no classes or JARs 
>> could be loaded at all! This patch causes the ClassLoader to not be 
>> so optimistic about finding an external main-class - it actually 
>> checks for it first, and if it still can't be found on the codebase 
>> after searching all JARs, then a LaunchException is thrown. If it can 
>> be found, then the applet launch proceeds as normal at this step.
>>
>> Additionally, checkNotAllSignedWithUser can only be called once now 
>> in initializeResources. Previously, it could be called both due to an 
>> external main-class as well as mixed signing states of JARs in the 
>> applet - so if you had one signed JAR, one unsigned JAR, and an 
>> external main-class, you would be prompted twice about the mixed 
>> signing, as well as about trusting the signer of the signed JAR. 
>> Craziness. Now, the prompt about mixed signing should only appear once.
>>
>> ChangeLog:
>> * netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java: 
>> (initializeResources) perform search for main-class when suspected to 
>> be external. Only show mixed code signing prompt once during 
>> initialization. (checkNotAllSignedWithUser) refactor to remove local 
>> variable (promptUser)
>>
>> Thanks,
>>
>
> Updated patch, Jiri pointed out over IRC that the previous patch only 
> worked for plugin applets and excluded JNLP. This makes it work for 
> JNLP as well, and also cleans up how codebase loading is set up on a 
> classloader. It's now done during initialization, rather than being 
> handled after the fact by a static factory-ish method.
>
> Thanks,
>

Ping.

Thanks,

-- 
Andrew A


From aazores at redhat.com  Mon Jan 27 11:55:36 2014
From: aazores at redhat.com (Andrew Azores)
Date: Mon, 27 Jan 2014 14:55:36 -0500
Subject: [rfc][icedtea-web] (PR1264) Run in Sandbox button
In-Reply-To: <52D5AB8F.7030503@redhat.com>
References: <52D06D1F.7070301@redhat.com> <52D5AB8F.7030503@redhat.com>
Message-ID: <52E6B9B8.7040402@redhat.com>

On 01/14/2014 04:26 PM, Andrew Azores wrote:
> On 01/10/2014 04:58 PM, Andrew Azores wrote:
>> Hi,
>>
>> As inspired by an earlier mailing list thread [1]/[2]/[3], this patch 
>> introduces a new "Sandbox" button in the dialog that appears when a 
>> user is prompted to decide whether or not they trust the signer of an 
>> applet. If the user clicks "Run", then the applet proceeds as normal, 
>> being granted full Java Permissions (except in edge cases such as 
>> PR1592 - mixed JAR signing - and PR1513 - external main-class). If 
>> the user clicks "Sandbox", however, the classloader will treat the 
>> applet as if it is completely unsigned, and run it only with Sandbox 
>> Permissions, disregarding the fact that the applet has been signed.
>>
>> More work will need to be done with this patch once the 
>> PartiallySigned Dialogs patch goes in, so that that dialog also 
>> supports this action. This will be done at a later date in a new 
>> changeset.
>>
>> Automated tests have been largely left out of this patch since it 
>> deals with adding GUI elements, and the state of the ClassLoader 
>> itself cannot be directly influenced by a reproducer without 
>> interacting with security prompts (obviously). A small unit test was 
>> included to check the conversion between a new AppletAction enum type 
>> and arbitrary Object references - see the patch for the relevance of 
>> this enum and why this test needs to be done.
>>
>> Non-automated testing should involve:
>> 1) running unsigned applets and verifying that the CertWarning dialog 
>> does not appear
>> 2) running unsigned applets and verifying that there is no Sandbox 
>> button
>> 3) running signed applets and verifying that there is a Sandbox 
>> button, which is enabled iff the "always trust content" checkbox is 
>> NOT ticked
>> 4) running signed applets with the "Run" button results in a normal 
>> applet launch (same behaviour with and without patch applied)
>> 5) running signed applets with the "Sandbox" button results in the 
>> applet not being able to perform privileged actions
>>
>> Some sample signed applets to test with:
>> a) http://caff.de/applettest/Signed.html - once the applet launches, 
>> privileged actions include printing and saving local files. "Sandbox" 
>> mode should result in permission denied error dialogs
>> b) https://oasisweb.uga.edu/oasis.html - launch browser from terminal 
>> to run this test. The applet will attempt to read several system 
>> properties, which it will print out. In standard run, these will be 
>> successfully read. In Sandbox mode, permission denied errors will be 
>> printed instead.
>> c) JOGL tests at 
>> http://jogamp.org/deployment/jogamp-current/jogl-test-applets.html - 
>> launch browser from terminal to run this test. Running applets in 
>> Sandbox mode will cause most of the applets to fail at runtime, with 
>> AccessControlExceptions printed to the terminal.
>>
>> Known issues (needing discussion):
>> - The CertWarning dialog sometimes appears more than once for a given 
>> applet (this is existing behaviour) - once per certificate that the 
>> user needs to approve trust. It doesn't seem to make sense for the 
>> "Sandbox" button to only apply to some subset of JARs in an applet 
>> based on signers, rather it should simply apply to the entire applet. 
>> Should further CertWarnings simply not be shown after the first time, 
>> if the Sandbox option is chosen the first time? Currently the 
>> implementation sets the entire classloader to Sandbox mode when a 
>> Sandbox button is pressed, which *must* occur before any classes are 
>> loaded and assigned security descriptors, so pressing Sandbox the 
>> first time and Run the second time will still result in Sandboxed 
>> behaviour. Or, should subsequent CertWarnings still be shown but 
>> perhaps with the Run button disabled if Sandbox has been chosen at 
>> least once prior?
>> - The entire classloader is set to Sandbox mode, and this is not done 
>> with any more fine-grained control than this. If multiple applets are 
>> sharing the same classloader instance, then they will all be run 
>> sandboxed. This can be changed, but I think it's going to be a very 
>> rare situation where applets that are sharing a classloader will not 
>> all be trusted at the same level by the user. Leaving it as it is 
>> keeps the implementation simpler.
>>
>> ChangeLog:
>> Added "Sandbox" button to CertWarning dialogs, allowing signed applets
>> to be run with restricted permissions
>> * netx/net/sourceforge/jnlp/resources/Messages.properties: (ButSandbox,
>> LRunInSandboxError, LRunInSandboxErrorInfo): new messages
>> * netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java: (security)
>> initialize to null when declared. (runInSandbox) new field.
>> (getRunInSandbox) getter for new field. (setRunInSandbox) set the
>> classloader to run current applet sandboxed. (activateJars,
>> initializeResources, addNewJar, setSecurity) assign sandbox permissions
>> regardless of signing if runInSandbox is set. (createInstance) do not 
>> show
>> unsigned applet prompt if runInSandbox is set.
>> * netx/net/sourceforge/jnlp/security/AppVerifier.java:
>> (checkTrustWithUser) added JNLPClassLoader param
>> * netx/net/sourceforge/jnlp/security/CertWarningPane.java: added Sandbox
>> button
>> * netx/net/sourceforge/jnlp/security/JNLPAppVerifier.java:
>> (checkTrustWithUser) uses AppletAction enum type, calls
>> JNLPClassLoader#setRunInSandbox if AppletAction is SANDBOX
>> * netx/net/sourceforge/jnlp/security/PluginAppVerifier.java: same
>> * netx/net/sourceforge/jnlp/security/SecurityDialogs.java: added
>> (AppletAction) enum type. (showCertWarning) returns AppletAction
>> rather than boolean
>> * netx/net/sourceforge/jnlp/security/VariableX509TrustManager.java:
>> (askUser) refactor to use AppletAction rather than boolean
>> * netx/net/sourceforge/jnlp/tools/JarCertVerifier.java:
>> (checkTrustWithUser) added JNLPClassLoader param
>> * 
>> tests/netx/unit/net/sourceforge/jnlp/security/SecurityDialogsTest.java:
>> (testGetIntegerResponseAsAppletAction) new tests for converting Object
>> references into AppletActions
>>
>>
>> [1] 
>> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2013-October/025394.html
>> [2] 
>> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2013-November/025396.html
>> [3] 
>> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2013-December/025399.html
>>
>> Thanks,
>>
>
> Again, updating the patches here due to discussions on IRC.
>
> Changes since the last set:
> - There's a new "-Xtrustnone" switch for command-line javaws. This is 
> like -Xtrustall but rather than choosing the "Run/Proceed" option, the 
> "Sandbox" option is taken.
>     - this is used for the new reproducer that is included, which 
> verifies that the Run in Sandbox button really does reduce the 
> permissions of a signed applet
> - part of JNLPClassLoader#initializeResources was refactored
> - the buttons on CertWarningDialogs now have tooltips
> - Clicking "Sandbox" on a CertWarningDialog causes any subsequent 
> CertWarningDialogs to not appear, at least not from the same 
> classloader. In the unusual cases where an applet has multiple 
> classloaders (eg some of the jogl jnlp applets), then multiple dialogs 
> may still appear.
>
> Thanks,
>

Ping.

Thanks,

-- 
Andrew A


From bugzilla-daemon at icedtea.classpath.org  Mon Jan 27 14:41:45 2014
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Mon, 27 Jan 2014 22:41:45 +0000
Subject: [Bug 1657] New: Java VM crash SIGSEGV
Message-ID: 

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

            Bug ID: 1657
           Summary: Java VM crash SIGSEGV
    Classification: Unclassified
           Product: IcedTea
           Version: unspecified
          Hardware: x86_64
                OS: Linux
            Status: NEW
          Severity: critical
          Priority: P3
         Component: IcedTea
          Assignee: gnu.andrew at redhat.com
          Reporter: classpath.org at a.blewski.com
                CC: unassigned at icedtea.classpath.org

Created attachment 1013
  --> http://icedtea.classpath.org/bugzilla/attachment.cgi?id=1013&action=edit
the hs_error.log file

Crash when running a program. has occured 2-3 times. 

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fd62c092921, pid=15459, tid=140557643228928
#
# JRE version: OpenJDK Runtime Environment (7.0_45-b15) (build
1.7.0_45-mockbuild_2013_10_16_17_51-b00)
# Java VM: OpenJDK 64-Bit Server VM (24.45-b08 mixed mode linux-amd64
compressed oops)
# Problematic frame:
# V  [libjvm.so+0x582921]  AsyncGetCallTrace+0xa0101
#

-- 
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/20140127/85401bd7/attachment.html 

From gitne at gmx.de  Mon Jan 27 14:50:58 2014
From: gitne at gmx.de (Jacob Wisor)
Date: Mon, 27 Jan 2014 23:50:58 +0100
Subject: /hg/icedtea-web: Improve PolicyTool launch method in PolicyPanel
In-Reply-To: <52E67B66.1080805@redhat.com>
References: 	<52E2991C.1020606@gmx.de>
	<52E66F94.9010901@redhat.com> <52E67B66.1080805@redhat.com>
Message-ID: <52E6E2D2.3080009@gmx.de>

On 01/27/2014 04:29 PM, Andrew Azores wrote:
> On 01/27/2014 09:39 AM, Jiri Vanek wrote:
> [...]
>>>> +        Class[] signature = new Class[] { String[].class };
>>>
>>> Redundant. No need to create a new instance here at run-time.
>>>
>>>> +        Method main = policyTool.getDeclaredMethod("main", signature);
>>>
>>> Just substitute "signature" with "String[].class".
>>>
>>>> +        Object args = new String[] { "-file", filePath };
>>>
>>> Why is "args" of type Object? String[] should be fine and Method.invoke()
>>> won't complain because
>>> String[] inherits from Object. ;-)
>>>
>> Especially this.. My overlook.
>
> Method#invoke has signature(Object, Object...) - the first being the object the
> method is to be invoked on, and the second being a varargs list for the method
> call. Yes, String[] inherits from Object, and it also confuses the varargs
> invocation. Hopefully this notation will make sense, but what I am doing here
> results in this method call being invoked:
>
> PolicyTool.main({"-file", filePath})
>
> and what you are suggesting results in this:
>
> PolicyTool.main("-file", filePath)
>
> These are not the same and in fact the second call will fail because there is no
> PolicyTool.main(String, String) method, so you get IllegalArgumentException:
> wrong number of arguments.

Oh I see. You avoid doing an explicit cast to Object later because the compiler 
is unsure whether an implicit cast from String[] to Object[] should be 
interpreted as a vararg (Object[]) or a formal parameter (Object). Since the 
compiler has been "automagically" creating Object[] arrays for varargs ever 
since then your code is okay.

> The "signature" variable is indeed not necessary but I'm really surprised that
> we're getting to the level of nitpicking on inlining variables here.
> Does this matter so much that it's worth patching?

This would just save some unnecessary operations on the stack. So, no probably 
not. For some it is just a matter of style.

But, you *should* probably change the call from Class.getDeclaredMethod() to 
Class.getMethod() because Class.getDeclaredMethod() assumes access to all, 
including non-public methods which causes a SecurityManager.checkMemberAccess(). 
This may lead to failure if the default SecurityManager is set. 
Class.getMethod() by definition accesses public members only hence it will not 
error out even with the default SecurityManager set (unless configured to deny 
access to public members). Or, has Class.getDeclaredMethod() been intentional too?

> Should we not be ensuring that we only invoke JOptionPane.showMessageDialog from
> the EDT? We have two different convenience methods that make this call, and
> *usually* these methods are all called from the main thread, but there is an
> occasion where we call showCouldNotOpenFileDialog from policyToolLaunchHelper,
> and this time it's occurring in a new thread. So we can either wrap this one
> particular call in an invokeLater, or just be completely sure that these two
> convenience methods are always used safely and put the invokeLater directly
> within them. In most cases, yes, it ends up being redundant, but it also means
> in every case it's done safely, doesn't it?
>
> Here's a small StackOverflow discussion I found while double checking myself on
> this.
>
> https://stackoverflow.com/questions/13863713/which-thread-to-launch-joptionpane

Oh, you want to make sure the call to JOptionPane.showMessageDialog() happens on 
the EDT for it to block. Then this is okay. Good job! :-) I have missed your 
intention because I assumed you just wanted to make sure IcedTea-Web's JFrame 
would process all events before getting to JOptionPane.showMessageDialog().

Jacob

From stefan.reich.maker.of.eye at googlemail.com  Mon Jan 27 14:58:14 2014
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Mon, 27 Jan 2014 23:58:14 +0100
Subject: I'm unsubscribing from IcedTea for now...
Message-ID: 

...but I'll be back!

Haha :)

Have a nice day and join the revolution!

Cheers,
Stefan


TinyBrain.de // We'll beat Google to A.I.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140127/3ae64822/attachment.html 

From stefan.reich.maker.of.eye at googlemail.com  Mon Jan 27 15:09:41 2014
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Tue, 28 Jan 2014 00:09:41 +0100
Subject: Hey wait, I'll stay a little.
Message-ID: 

Ah. Just chatting you up a little :)

We need more out-of-protocol communications.

Really!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140128/8bd93e9d/attachment.html 

From emailgrant at gmail.com  Mon Jan 27 15:28:37 2014
From: emailgrant at gmail.com (Grant)
Date: Mon, 27 Jan 2014 15:28:37 -0800
Subject: building icedtea-7 on ARM
In-Reply-To: <52D6AC0D.6090905@RedHat.Com>
References: 
	<52CFBD29.4000502@redhat.com>
	
	
	<52D6A58F.7060909@redhat.com> <52D6AC0D.6090905@RedHat.Com>
Message-ID: 

>>> Hi Andrew, can you point me in the right direction with this?  Here
>>> are a couple errors I'm getting depending on compile options and
>>> bootstrap VM:
>>>
>>> http://pastebin.com/VV3rMezP
>>> http://pastebin.com/ThjufjyH
>>
>> This may be the bug that Chris Philips is working on.
>>
>> Chris?
>>
>> Andrew.
>>
> Neither of these look familiar (though I recollect some issues in the
> cryptocheck
> for other archs so it may be a generic failure...).
> I am planning update the it7-head forest with latest arm32 stuff in near
> future so it
> might be better to await that event. (Near future ~ a week +/- ).
>
> Chris

Does anyone know where I can check to see if this has been updated?

- Grant

From gnu.andrew at redhat.com  Mon Jan 27 21:21:07 2014
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 28 Jan 2014 00:21:07 -0500 (EST)
Subject: building icedtea-7 on ARM
In-Reply-To: 
References: 
	<52CFBD29.4000502@redhat.com>
	
	
	<52D6A58F.7060909@redhat.com> <52D6AC0D.6090905@RedHat.Com>
	
Message-ID: <1800522928.83487.1390886467315.JavaMail.root@redhat.com>



----- Original Message -----
> >>> Hi Andrew, can you point me in the right direction with this?  Here
> >>> are a couple errors I'm getting depending on compile options and
> >>> bootstrap VM:
> >>>
> >>> http://pastebin.com/VV3rMezP
> >>> http://pastebin.com/ThjufjyH
> >>
> >> This may be the bug that Chris Philips is working on.
> >>
> >> Chris?
> >>
> >> Andrew.
> >>
> > Neither of these look familiar (though I recollect some issues in the
> > cryptocheck
> > for other archs so it may be a generic failure...).
> > I am planning update the it7-head forest with latest arm32 stuff in near
> > future so it
> > might be better to await that event. (Near future ~ a week +/- ).
> >
> > Chris
> 
> Does anyone know where I can check to see if this has been updated?
> 
> - Grant
> 

http://icedtea.classpath.org/hg/icedtea7-forest/hotspot

Nothing yet. I'll ping this thread when something happens.
-- 
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 icedtea.classpath.org  Tue Jan 28 01:15:19 2014
From: ptisnovs at icedtea.classpath.org (ptisnovs at icedtea.classpath.org)
Date: Tue, 28 Jan 2014 09:15:19 +0000
Subject: /hg/gfx-test: Added five new tests into the testsuite CAGOperati...
Message-ID: 

changeset 2da99235dc05 in /hg/gfx-test
details: http://icedtea.classpath.org/hg/gfx-test?cmd=changeset;node=2da99235dc05
author: Pavel Tisnovsky 
date: Tue Jan 28 10:19:36 2014 +0100

	Added five new tests into the testsuite CAGOperationsOnTwoTouchingCircles.


diffstat:

 ChangeLog                                                         |    5 +
 src/org/gfxtest/testsuites/CAGOperationsOnTwoTouchingCircles.java |  127 +++++++++-
 2 files changed, 131 insertions(+), 1 deletions(-)

diffs (156 lines):

diff -r 115b6ea402f8 -r 2da99235dc05 ChangeLog

--- a/ChangeLog	Mon Jan 27 12:49:11 2014 +0100
+++ b/ChangeLog	Tue Jan 28 10:19:36 2014 +0100
@@ -1,3 +1,8 @@
+2014-01-28  Pavel Tisnovsky  
+
+	* src/org/gfxtest/testsuites/CAGOperationsOnTwoTouchingCircles.java:
+	Added five new tests into the testsuite CAGOperationsOnTwoTouchingCircles.
+
 2014-01-27  Pavel Tisnovsky  
 
 	* src/org/gfxtest/testsuites/CAGOperationsOnRoundRectangleAndRectangle.java:
diff -r 115b6ea402f8 -r 2da99235dc05 src/org/gfxtest/testsuites/CAGOperationsOnTwoTouchingCircles.java
--- a/src/org/gfxtest/testsuites/CAGOperationsOnTwoTouchingCircles.java	Mon Jan 27 12:49:11 2014 +0100
+++ b/src/org/gfxtest/testsuites/CAGOperationsOnTwoTouchingCircles.java	Tue Jan 28 10:19:36 2014 +0100
@@ -1,7 +1,7 @@
 /*
   Java gfx-test framework
 
-   Copyright (C) 2010, 2011  Red Hat
+   Copyright (C) 2010, 2011, 2012, 2013, 2014  Red Hat
 
 This file is part of IcedTea.
 
@@ -435,6 +435,131 @@
     /**
      * Checks the process of creating and rendering new geometric shape
      * constructed from two touching circles using union operator. The shape is rendered
+     * using zero wide stroke.
+     * 
+     * @param image
+     *            image to which area is to be drawn
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testUnionZeroStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // set stroke color
+        CommonRenderingStyles.setStrokeColor(graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeZeroThick(graphics2d);
+        // create area using union operator
+        Area area = CommonCAGOperations.createAreaFromTwoTouchingCirclesUsingUnionOperator(image);
+        // draw the area
+        graphics2d.draw(area);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Checks the process of creating and rendering new geometric shape
+     * constructed from two touching circles using subtract operator. The shape is
+     * rendered using zero stroke.
+     * 
+     * @param image
+     *            image to which area is to be drawn
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testSubtractZeroStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // set stroke color
+        CommonRenderingStyles.setStrokeColor(graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeZeroThick(graphics2d);
+        // create area using subtract operator
+        Area area = CommonCAGOperations.createAreaFromTwoTouchingCirclesUsingSubtractOperator(image);
+        // draw the area
+        graphics2d.draw(area);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Checks the process of creating and rendering new geometric shape
+     * constructed from two touching circles using inverse subtract operator. The shape
+     * is rendered using zero stroke.
+     * 
+     * @param image
+     *            image to which area is to be drawn
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testInverseSubtractZeroStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // set stroke color
+        CommonRenderingStyles.setStrokeColor(graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeZeroThick(graphics2d);
+        // create area using subtract operator
+        Area area = CommonCAGOperations.createAreaFromTwoTouchingCirclesUsingInverseSubtractOperator(image);
+        // draw the area
+        graphics2d.draw(area);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Checks the process of creating and rendering new geometric shape
+     * constructed from two touching circles using intersect operator. The shape is
+     * rendered using zero stroke.
+     * 
+     * @param image
+     *            image to which area is to be drawn
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testIntersectZeroStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // set stroke color
+        CommonRenderingStyles.setStrokeColor(graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeZeroThick(graphics2d);
+        // create area using intersect operator
+        Area area = CommonCAGOperations.createAreaFromTwoTouchingCirclesUsingIntersectOperator(image);
+        // draw the area
+        graphics2d.draw(area);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Checks the process of creating and rendering new geometric shape
+     * constructed from two touching circles using XOR operator. The shape is rendered
+     * using zero stroke.
+     * 
+     * @param image
+     *            image to which area is to be drawn
+     * @param graphics2d
+     *            graphics canvas
+     * @return test result status - PASSED, FAILED or ERROR
+     */
+    public TestResult testXorZeroStrokePaint(TestImage image, Graphics2D graphics2d)
+    {
+        // set stroke color
+        CommonRenderingStyles.setStrokeColor(graphics2d);
+        // set stroke width
+        CommonRenderingStyles.setStrokeZeroThick(graphics2d);
+        // create area using XOR operator
+        Area area = CommonCAGOperations.createAreaFromTwoTouchingCirclesUsingXorOperator(image);
+        // draw the area
+        graphics2d.draw(area);
+        // test result
+        return TestResult.PASSED;
+    }
+
+    /**
+     * Checks the process of creating and rendering new geometric shape
+     * constructed from two touching circles using union operator. The shape is rendered
      * using color paint (fill).
      * 
      * @param image

From ptisnovs at icedtea.classpath.org  Tue Jan 28 01:43:08 2014
From: ptisnovs at icedtea.classpath.org (ptisnovs at icedtea.classpath.org)
Date: Tue, 28 Jan 2014 09:43:08 +0000
Subject: /hg/rhino-tests: Enhancement of the test testGetResourceAsStream...
Message-ID: 

changeset 73503cadcb15 in /hg/rhino-tests
details: http://icedtea.classpath.org/hg/rhino-tests?cmd=changeset;node=73503cadcb15
author: Pavel Tisnovsky 
date: Tue Jan 28 10:47:26 2014 +0100

	Enhancement of the test testGetResourceAsStreamNegativeTest.


diffstat:

 ChangeLog                                            |    5 +
 src/org/RhinoTests/ScriptEngineManagerClassTest.java |  258 ++++++++++++++++++-
 2 files changed, 262 insertions(+), 1 deletions(-)

diffs (294 lines):

diff -r eb150896a385 -r 73503cadcb15 ChangeLog
--- a/ChangeLog	Mon Jan 27 12:52:02 2014 +0100
+++ b/ChangeLog	Tue Jan 28 10:47:26 2014 +0100
@@ -1,3 +1,8 @@
+2014-01-28  Pavel Tisnovsky  
+
+	* src/org/RhinoTests/ScriptEngineManagerClassTest.java:
+	Enhancement of the test testGetResourceAsStreamNegativeTest.
+
 2014-01-27  Pavel Tisnovsky  
 
 	* src/org/RhinoTests/ScriptEngineFactoryClassTest.java:
diff -r eb150896a385 -r 73503cadcb15 src/org/RhinoTests/ScriptEngineManagerClassTest.java
--- a/src/org/RhinoTests/ScriptEngineManagerClassTest.java	Mon Jan 27 12:52:02 2014 +0100
+++ b/src/org/RhinoTests/ScriptEngineManagerClassTest.java	Tue Jan 28 10:47:26 2014 +0100
@@ -1,7 +1,7 @@
 /*
   Rhino test framework
 
-   Copyright (C) 2011, 2012, 2013  Red Hat
+   Copyright (C) 2011, 2012, 2013, 2014  Red Hat
 
 This file is part of IcedTea.
 
@@ -1424,6 +1424,54 @@
         }
 
         try {
+            this.scriptEngineManagerClass.asSubclass(java.applet.Applet.class);
+            throw new AssertionError("Class.asSubclass(java.applet.Applet.class) does not throw any exception");
+        }
+        catch (Exception e) {
+            // expected exception
+        }
+
+        try {
+            this.scriptEngineManagerClass.asSubclass(java.awt.Button.class);
+            throw new AssertionError("Class.asSubclass(java.awt.Button.class) does not throw any exception");
+        }
+        catch (Exception e) {
+            // expected exception
+        }
+
+        try {
+            this.scriptEngineManagerClass.asSubclass(java.awt.Canvas.class);
+            throw new AssertionError("Class.asSubclass(java.awt.Canvas.class) does not throw any exception");
+        }
+        catch (Exception e) {
+            // expected exception
+        }
+
+        try {
+            this.scriptEngineManagerClass.asSubclass(java.awt.CardLayout.class);
+            throw new AssertionError("Class.asSubclass(java.awt.CardLayout.class) does not throw any exception");
+        }
+        catch (Exception e) {
+            // expected exception
+        }
+
+        try {
+            this.scriptEngineManagerClass.asSubclass(java.awt.Checkbox.class);
+            throw new AssertionError("Class.asSubclass(java.awt.Checkbox.class) does not throw any exception");
+        }
+        catch (Exception e) {
+            // expected exception
+        }
+
+        try {
+            this.scriptEngineManagerClass.asSubclass(java.awt.Choice.class);
+            throw new AssertionError("Class.asSubclass(java.awt.Choice.class) does not throw any exception");
+        }
+        catch (Exception e) {
+            // expected exception
+        }
+
+        try {
             this.scriptEngineManagerClass.asSubclass(java.awt.Color.class);
             throw new AssertionError("Class.asSubclass(java.awt.Color.class) does not throw any exception");
         }
@@ -1448,6 +1496,214 @@
         }
 
         try {
+            this.scriptEngineManagerClass.asSubclass(java.awt.Label.class);
+            throw new AssertionError("Class.asSubclass(java.awt.Label.class) does not throw any exception");
+        }
+        catch (Exception e) {
+            // expected exception
+        }
+
+        try {
+            this.scriptEngineManagerClass.asSubclass(java.awt.List.class);
+            throw new AssertionError("Class.asSubclass(java.awt.List.class) does not throw any exception");
+        }
+        catch (Exception e) {
+            // expected exception
+        }
+
+        try {
+            this.scriptEngineManagerClass.asSubclass(java.awt.Menu.class);
+            throw new AssertionError("Class.asSubclass(java.awt.Menu.class) does not throw any exception");
+        }
+        catch (Exception e) {
+            // expected exception
+        }
+
+        try {
+            this.scriptEngineManagerClass.asSubclass(java.io.File.class);
+            throw new AssertionError("Class.asSubclass(java.io.File.class) does not throw any exception");
+        }
+        catch (Exception e) {
+            // expected exception
+        }
+
+        try {
+            this.scriptEngineManagerClass.asSubclass(java.io.Reader.class);
+            throw new AssertionError("Class.asSubclass(java.io.Reader.class) does not throw any exception");
+        }
+        catch (Exception e) {
+            // expected exception
+        }
+
+        try {
+            this.scriptEngineManagerClass.asSubclass(java.io.Writer.class);
+            throw new AssertionError("Class.asSubclass(java.io.Writer.class) does not throw any exception");
+        }
+        catch (Exception e) {
+            // expected exception
+        }
+
+        try {
+            this.scriptEngineManagerClass.asSubclass(java.io.StringReader.class);
+            throw new AssertionError("Class.asSubclass(java.io.StringReader.class) does not throw any exception");
+        }
+        catch (Exception e) {
+            // expected exception
+        }
+
+        try {
+            this.scriptEngineManagerClass.asSubclass(java.io.StringWriter.class);
+            throw new AssertionError("Class.asSubclass(java.io.StringWriter.class) does not throw any exception");
+        }
+        catch (Exception e) {
+            // expected exception
+        }
+
+        try {
+            this.scriptEngineManagerClass.asSubclass(java.io.InputStream.class);
+            throw new AssertionError("Class.asSubclass(java.io.InputStream.class) does not throw any exception");
+        }
+        catch (Exception e) {
+            // expected exception
+        }
+
+        try {
+            this.scriptEngineManagerClass.asSubclass(java.io.OutputStream.class);
+            throw new AssertionError("Class.asSubclass(java.io.OutputStream.class) does not throw any exception");
+        }
+        catch (Exception e) {
+            // expected exception
+        }
+
+        try {
+            this.scriptEngineManagerClass.asSubclass(java.io.ObjectInputStream.class);
+            throw new AssertionError("Class.asSubclass(java.io.ObjectInputStream.class) does not throw any exception");
+        }
+        catch (Exception e) {
+            // expected exception
+        }
+
+        try {
+            this.scriptEngineManagerClass.asSubclass(java.io.ObjectOutputStream.class);
+            throw new AssertionError("Class.asSubclass(java.io.ObjectOutputStream.class) does not throw any exception");
+        }
+        catch (Exception e) {
+            // expected exception
+        }
+
+        try {
+            this.scriptEngineManagerClass.asSubclass(java.math.BigDecimal.class);
+            throw new AssertionError("Class.asSubclass(java.math.BigDecimal.class) does not throw any exception");
+        }
+        catch (Exception e) {
+            // expected exception
+        }
+
+        try {
+            this.scriptEngineManagerClass.asSubclass(java.math.BigInteger.class);
+            throw new AssertionError("Class.asSubclass(java.math.BigInteger.class) does not throw any exception");
+        }
+        catch (Exception e) {
+            // expected exception
+        }
+
+        try {
+            this.scriptEngineManagerClass.asSubclass(java.util.ArrayList.class);
+            throw new AssertionError("Class.asSubclass(java.util.ArrayList.class) does not throw any exception");
+        }
+        catch (Exception e) {
+            // expected exception
+        }
+
+        try {
+            this.scriptEngineManagerClass.asSubclass(java.util.LinkedList.class);
+            throw new AssertionError("Class.asSubclass(java.util.LinkedList.class) does not throw any exception");
+        }
+        catch (Exception e) {
+            // expected exception
+        }
+
+        try {
+            this.scriptEngineManagerClass.asSubclass(java.util.HashMap.class);
+            throw new AssertionError("Class.asSubclass(java.util.HashMap.class) does not throw any exception");
+        }
+        catch (Exception e) {
+            // expected exception
+        }
+
+        try {
+            this.scriptEngineManagerClass.asSubclass(java.util.TreeMap.class);
+            throw new AssertionError("Class.asSubclass(java.util.TreeMap.class) does not throw any exception");
+        }
+        catch (Exception e) {
+            // expected exception
+        }
+
+        try {
+            this.scriptEngineManagerClass.asSubclass(java.util.HashSet.class);
+            throw new AssertionError("Class.asSubclass(java.util.HashSet.class) does not throw any exception");
+        }
+        catch (Exception e) {
+            // expected exception
+        }
+
+        try {
+            this.scriptEngineManagerClass.asSubclass(java.util.TreeSet.class);
+            throw new AssertionError("Class.asSubclass(java.util.TreeSet.class) does not throw any exception");
+        }
+        catch (Exception e) {
+            // expected exception
+        }
+
+        try {
+            this.scriptEngineManagerClass.asSubclass(java.util.Stack.class);
+            throw new AssertionError("Class.asSubclass(java.util.Stack.class) does not throw any exception");
+        }
+        catch (Exception e) {
+            // expected exception
+        }
+
+        try {
+            this.scriptEngineManagerClass.asSubclass(java.util.Vector.class);
+            throw new AssertionError("Class.asSubclass(java.util.Vector.class) does not throw any exception");
+        }
+        catch (Exception e) {
+            // expected exception
+        }
+
+        try {
+            this.scriptEngineManagerClass.asSubclass(java.util.Hashtable.class);
+            throw new AssertionError("Class.asSubclass(java.util.Hashtable.class) does not throw any exception");
+        }
+        catch (Exception e) {
+            // expected exception
+        }
+
+        try {
+            this.scriptEngineManagerClass.asSubclass(java.util.Calendar.class);
+            throw new AssertionError("Class.asSubclass(java.util.Calendar.class) does not throw any exception");
+        }
+        catch (Exception e) {
+            // expected exception
+        }
+
+        try {
+            this.scriptEngineManagerClass.asSubclass(java.util.Arrays.class);
+            throw new AssertionError("Class.asSubclass(java.util.Arrays.class) does not throw any exception");
+        }
+        catch (Exception e) {
+            // expected exception
+        }
+
+        try {
+            this.scriptEngineManagerClass.asSubclass(java.util.Collections.class);
+            throw new AssertionError("Class.asSubclass(java.util.Collections.class) does not throw any exception");
+        }
+        catch (Exception e) {
+            // expected exception
+        }
+
+        try {
             this.scriptEngineManagerClass.asSubclass(javax.swing.JPanel.class);
             throw new AssertionError("Class.asSubclass(javax.swing.JPanel.class) does not throw any exception");
         }

From andrew at icedtea.classpath.org  Tue Jan 28 02:54:44 2014
From: andrew at icedtea.classpath.org (andrew at icedtea.classpath.org)
Date: Tue, 28 Jan 2014 10:54:44 +0000
Subject: /hg/release/icedtea7-forest-2.4/corba: 2 new changesets
Message-ID: 

changeset adc241d706d6 in /hg/release/icedtea7-forest-2.4/corba
details: http://icedtea.classpath.org/hg/release/icedtea7-forest-2.4/corba?cmd=changeset;node=adc241d706d6
author: andrew
date: Thu Jan 23 22:40:30 2014 +0000

	PR1653: Support ppc64le via Zero


changeset 3594dbde270d in /hg/release/icedtea7-forest-2.4/corba
details: http://icedtea.classpath.org/hg/release/icedtea7-forest-2.4/corba?cmd=changeset;node=3594dbde270d
author: andrew
date: Thu Jan 23 23:19:18 2014 +0000

	PR1654: ppc32 needs a larger ThreadStackSize to build


diffstat:

 make/common/shared/Defs-java.gmk |  6 +++++-
 make/common/shared/Platform.gmk  |  2 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

diffs (28 lines):

diff -r 721b1070efda -r 3594dbde270d make/common/shared/Defs-java.gmk
--- a/make/common/shared/Defs-java.gmk	Fri Jan 17 20:22:44 2014 +0000
+++ b/make/common/shared/Defs-java.gmk	Thu Jan 23 23:19:18 2014 +0000
@@ -79,7 +79,11 @@
 
 # 64-bit builds require a larger thread stack size.
 ifeq ($(ARCH_DATA_MODEL), 32)
-  JAVAC_JVM_FLAGS    += -J-XX:ThreadStackSize=768
+  ifeq ($(ARCH), ppc)
+    JAVAC_JVM_FLAGS    += -J-XX:ThreadStackSize=1152
+  else
+    JAVAC_JVM_FLAGS    += -J-XX:ThreadStackSize=768
+  endif
 else
   JAVAC_JVM_FLAGS    += -J-XX:ThreadStackSize=1664
 endif
diff -r 721b1070efda -r 3594dbde270d make/common/shared/Platform.gmk
--- a/make/common/shared/Platform.gmk	Fri Jan 17 20:22:44 2014 +0000
+++ b/make/common/shared/Platform.gmk	Thu Jan 23 23:19:18 2014 +0000
@@ -154,7 +154,7 @@
   # Arch and OS name/version
   mach := $(shell uname -m)
   ifneq (,$(wildcard /usr/bin/dpkg-architecture))
-    mach := $(shell (dpkg-architecture -qDEB_HOST_ARCH_CPU 2>/dev/null || echo $(mach)) | sed 's/arm64/aarch64/;s/powerpc$$/ppc/;s/hppa/parisc/')
+    mach := $(shell (dpkg-architecture -qDEB_HOST_ARCH_CPU 2>/dev/null || echo $(mach)) | sed 's/arm64/aarch64/;s/powerpc$$/ppc/;s/hppa/parisc/;s/ppc64el/ppc64le/')
   endif
   archExpr = case "$(mach)" in \
                 i[3-9]86) \

From bugzilla-daemon at icedtea.classpath.org  Tue Jan 28 02:54:54 2014
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Tue, 28 Jan 2014 10:54:54 +0000
Subject: [Bug 1653] [IcedTea7] Support ppc64le via Zero
In-Reply-To: 
References: 
Message-ID: 

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

--- Comment #5 from hg commits  ---
details:
http://icedtea.classpath.org//hg/release/icedtea7-forest-2.4/corba?cmd=changeset;node=adc241d706d6
author: andrew
date: Thu Jan 23 22:40:30 2014 +0000

    PR1653: Support ppc64le via Zero

-- 
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/20140128/1f05c3e4/attachment.html 

From bugzilla-daemon at icedtea.classpath.org  Tue Jan 28 02:55:04 2014
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Tue, 28 Jan 2014 10:55:04 +0000
Subject: [Bug 1654] [IcedTea7] ppc32 needs a larger ThreadStackSize to build
In-Reply-To: 
References: 
Message-ID: 

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

--- Comment #4 from hg commits  ---
details:
http://icedtea.classpath.org//hg/release/icedtea7-forest-2.4/corba?cmd=changeset;node=3594dbde270d
author: andrew
date: Thu Jan 23 23:19:18 2014 +0000

    PR1654: ppc32 needs a larger ThreadStackSize to build

-- 
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/20140128/0dc560e2/attachment.html 

From andrew at icedtea.classpath.org  Tue Jan 28 02:55:30 2014
From: andrew at icedtea.classpath.org (andrew at icedtea.classpath.org)
Date: Tue, 28 Jan 2014 10:55:30 +0000
Subject: /hg/release/icedtea7-forest-2.4/hotspot: PR1653: Support ppc64le...
Message-ID: 

changeset cbeecad5efcb in /hg/release/icedtea7-forest-2.4/hotspot
details: http://icedtea.classpath.org/hg/release/icedtea7-forest-2.4/hotspot?cmd=changeset;node=cbeecad5efcb
author: andrew
date: Thu Jan 23 22:41:21 2014 +0000

	PR1653: Support ppc64le via Zero


diffstat:

 src/os_cpu/linux_zero/vm/globals_linux_zero.hpp |  6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diffs (24 lines):

diff -r 659dc7b310ea -r cbeecad5efcb src/os_cpu/linux_zero/vm/globals_linux_zero.hpp
--- a/src/os_cpu/linux_zero/vm/globals_linux_zero.hpp	Fri Jan 17 20:22:50 2014 +0000
+++ b/src/os_cpu/linux_zero/vm/globals_linux_zero.hpp	Thu Jan 23 22:41:21 2014 +0000
@@ -26,6 +26,8 @@
 #ifndef OS_CPU_LINUX_ZERO_VM_GLOBALS_LINUX_ZERO_HPP
 #define OS_CPU_LINUX_ZERO_VM_GLOBALS_LINUX_ZERO_HPP
 
+#include "utilities/macros.hpp"
+
 //
 // Set the default values for platform dependent flags used by the
 // runtime system.  See globals.hpp for details of what they do.
@@ -34,9 +36,9 @@
 define_pd_global(bool,  DontYieldALot,           false);
 define_pd_global(intx,  ThreadStackSize,         1664);
 #ifdef _LP64
-define_pd_global(intx,  VMThreadStackSize,       1024);
+define_pd_global(intx,  VMThreadStackSize,       PPC_ONLY(1664) NOT_PPC(1024));
 #else
-define_pd_global(intx,  VMThreadStackSize,       512);
+define_pd_global(intx,  VMThreadStackSize,       PPC_ONLY(1152) NOT_PPC(512));
 #endif // _LP64
 define_pd_global(intx,  CompilerThreadStackSize, 0);
 define_pd_global(uintx, JVMInvokeMethodSlack,    8192);

From bugzilla-daemon at icedtea.classpath.org  Tue Jan 28 02:55:37 2014
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Tue, 28 Jan 2014 10:55:37 +0000
Subject: [Bug 1653] [IcedTea7] Support ppc64le via Zero
In-Reply-To: 
References: 
Message-ID: 

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

--- Comment #6 from hg commits  ---
details:
http://icedtea.classpath.org//hg/release/icedtea7-forest-2.4/hotspot?cmd=changeset;node=cbeecad5efcb
author: andrew
date: Thu Jan 23 22:41:21 2014 +0000

    PR1653: Support ppc64le via Zero

-- 
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/20140128/88c4b9d4/attachment-0001.html 

From andrew at icedtea.classpath.org  Tue Jan 28 02:55:50 2014
From: andrew at icedtea.classpath.org (andrew at icedtea.classpath.org)
Date: Tue, 28 Jan 2014 10:55:50 +0000
Subject: /hg/release/icedtea7-forest-2.4/jdk: 2 new changesets
Message-ID: 

changeset 2ef049ab5b37 in /hg/release/icedtea7-forest-2.4/jdk
details: http://icedtea.classpath.org/hg/release/icedtea7-forest-2.4/jdk?cmd=changeset;node=2ef049ab5b37
author: andrew
date: Thu Jan 23 22:41:14 2014 +0000

	PR1653: Support ppc64le via Zero


changeset a74c2e4a756b in /hg/release/icedtea7-forest-2.4/jdk
details: http://icedtea.classpath.org/hg/release/icedtea7-forest-2.4/jdk?cmd=changeset;node=a74c2e4a756b
author: andrew
date: Thu Jan 23 23:19:20 2014 +0000

	PR1654: ppc32 needs a larger ThreadStackSize to build


diffstat:

 make/common/shared/Defs-java.gmk |  6 +++++-
 make/common/shared/Platform.gmk  |  6 +++---
 make/jdk_generic_profile.sh      |  7 ++++---
 3 files changed, 12 insertions(+), 7 deletions(-)

diffs (79 lines):

diff -r 53ebbd107ffa -r a74c2e4a756b make/common/shared/Defs-java.gmk
--- a/make/common/shared/Defs-java.gmk	Fri Jan 17 20:23:01 2014 +0000
+++ b/make/common/shared/Defs-java.gmk	Thu Jan 23 23:19:20 2014 +0000
@@ -88,7 +88,11 @@
 
 # 64-bit builds require a larger thread stack size.
 ifeq ($(ARCH_DATA_MODEL), 32)
-  JAVAC_JVM_FLAGS    += -J-XX:ThreadStackSize=768
+  ifeq ($(ARCH), ppc)
+    JAVAC_JVM_FLAGS    += -J-XX:ThreadStackSize=1152
+  else
+    JAVAC_JVM_FLAGS    += -J-XX:ThreadStackSize=768
+  endif
 else
   JAVAC_JVM_FLAGS    += -J-XX:ThreadStackSize=1664
 endif
diff -r 53ebbd107ffa -r a74c2e4a756b make/common/shared/Platform.gmk
--- a/make/common/shared/Platform.gmk	Fri Jan 17 20:23:01 2014 +0000
+++ b/make/common/shared/Platform.gmk	Thu Jan 23 23:19:20 2014 +0000
@@ -161,7 +161,7 @@
     mach := $(shell uname -m)
   endif
   ifneq (,$(wildcard /usr/bin/dpkg-architecture))
-    mach := $(shell (dpkg-architecture -qDEB_HOST_ARCH_CPU 2>/dev/null || echo $(mach)) | sed 's/arm64/aarch64/;s/powerpc$$/ppc/;s/hppa/parisc/')
+    mach := $(shell (dpkg-architecture -qDEB_HOST_ARCH_CPU 2>/dev/null || echo $(mach)) | sed 's/arm64/aarch64/;s/powerpc$$/ppc/;s/hppa/parisc/;s/ppc64el/ppc64le/')
   endif
   archExpr = case "$(mach)" in \
                 i[3-9]86) \
@@ -205,10 +205,10 @@
     # Most archs are 32-bit
     ifndef ARCH_DATA_MODEL
       ARCH_DATA_MODEL=32
-      ifeq ($(ARCH), amd64)
+      ifneq (,$(findstring 64,$(ARCH)))
         ARCH_DATA_MODEL=64
       endif
-      ifeq ($(ARCH), ia64)
+      ifeq ($(ARCH), s390x)
         ARCH_DATA_MODEL=64
       endif
       ifeq ($(ARCH), sh)
diff -r 53ebbd107ffa -r a74c2e4a756b make/jdk_generic_profile.sh
--- a/make/jdk_generic_profile.sh	Fri Jan 17 20:23:01 2014 +0000
+++ b/make/jdk_generic_profile.sh	Thu Jan 23 23:19:20 2014 +0000
@@ -260,6 +260,7 @@
     sparc64) ZERO_LIBARCH=sparcv9   ;;
     arm*)    ZERO_LIBARCH=arm       ;;
     sh*)     ZERO_LIBARCH=sh        ;;
+    ppc64le) ZERO_LIBARCH=ppc64le   ;;
     *)       ZERO_LIBARCH="$(arch)"
   esac
   export ZERO_LIBARCH
@@ -269,7 +270,7 @@
     arm|i386|ppc|s390|sh|sparc)
       ARCH_DATA_MODEL=32
       ;;
-    aarch64|alpha|amd64|ia64|ppc64|s390x|sparcv9)
+    aarch64|alpha|amd64|ia64|ppc64*|s390x|sparcv9)
       ARCH_DATA_MODEL=64
       ;;
     *)
@@ -280,7 +281,7 @@
 
   # ZERO_ENDIANNESS is the endianness of the processor
   case "${ZERO_LIBARCH}" in
-    arm|aarch64|amd64|i386|ia64|mipsel)
+    arm|aarch64|amd64|i386|ia64|mipsel|ppc64le)
       ZERO_ENDIANNESS=little
       ;;
     ppc*|s390*|sparc*|alpha)
@@ -307,7 +308,7 @@
     s390)
       ZERO_ARCHFLAG="-m31"
       ;;
-    arm|aarch64)
+    arm|aarch64|ppc64le)
       ZERO_ARCHFLAG="-D_LITTLE_ENDIAN"
       ;;
     *)

From bugzilla-daemon at icedtea.classpath.org  Tue Jan 28 02:55:59 2014
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Tue, 28 Jan 2014 10:55:59 +0000
Subject: [Bug 1653] [IcedTea7] Support ppc64le via Zero
In-Reply-To: 
References: 
Message-ID: 

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

--- Comment #7 from hg commits  ---
details:
http://icedtea.classpath.org//hg/release/icedtea7-forest-2.4/jdk?cmd=changeset;node=2ef049ab5b37
author: andrew
date: Thu Jan 23 22:41:14 2014 +0000

    PR1653: Support ppc64le via Zero

-- 
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/20140128/36e3abd4/attachment.html 

From bugzilla-daemon at icedtea.classpath.org  Tue Jan 28 02:56:05 2014
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Tue, 28 Jan 2014 10:56:05 +0000
Subject: [Bug 1654] [IcedTea7] ppc32 needs a larger ThreadStackSize to build
In-Reply-To: 
References: 
Message-ID: 

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

--- Comment #5 from hg commits  ---
details:
http://icedtea.classpath.org//hg/release/icedtea7-forest-2.4/jdk?cmd=changeset;node=a74c2e4a756b
author: andrew
date: Thu Jan 23 23:19:20 2014 +0000

    PR1654: ppc32 needs a larger ThreadStackSize to build

-- 
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/20140128/a41bf33f/attachment.html 

From jvanek at redhat.com  Tue Jan 28 03:30:08 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Tue, 28 Jan 2014 12:30:08 +0100
Subject: /hg/icedtea-web: Improve PolicyTool launch method in PolicyPanel
In-Reply-To: <52E6B0AF.5050805@gmx.de>
References: 
	<52E2991C.1020606@gmx.de> <52E66F94.9010901@redhat.com>
	<52E6B0AF.5050805@gmx.de>
Message-ID: <52E794C0.4020002@redhat.com>

On 01/27/2014 08:17 PM, Jacob Wisor wrote:
> On 01/27/2014 03:39 PM, Jiri Vanek wrote:
>> ...
>>>> +     * @param filePath a {@link String} representing the path of the file to
>>>> attempt to open
>>>> +     * @throws Exception if any sort of exception occurs during reflective
>>>> launch of policytool
>>>> +     */
>>>> +    private static void reflectivePolicyToolLaunch(final String filePath)
>>>> throws Exception {
>>>> +        Class policyTool =
>>>> Class.forName("sun.security.tools.policytool.PolicyTool");
>>>
>>> What about JRE 6? You could catch a ClassNotFoundException here and then try
>>> to get
>>> sun.security.tools.PolicyTool. And, if that fails, well then... Blow up! :-D
>>
>> Well - why yes? The jdk6 is dead. We are dealing with slowly, but its true. The
>> command exec is what matters. The second one is fallback.
>>
>> If you have non-policytool command, non jdk7 system. Please go on and fix.
>> Otherwise I do not believe it is worthy.
>
> The reason I mentioned this is because as Andrew wants to backport this patch to 1.4 and many
> machines will probably still be running on a strict combination of IcedTea-Web 1.4 on JRE 6 (for
> various reasons), the fallback for the *new feature* introduced by it will not work on this
> combination. Your proposed quick "fix" is not always easily possible, eg. because some other major
> software requires JRE 6 to run. This is also one reason why I called this patch a *new feature* and
> am against backporting it. But, if the patch is going to be backported then please also make sure
> that IcedTea-Web 1.4 will run on JREs that were still in wide use during its initial release, like
> JRE 6. Yes, even when resorting to a fallback.


If you insists, then trying the jdk6 class is solution after ClassNotFound Exception.
>
> As a side note: Those version numbers have a meaning indeed. They are not just some sort of fancy
> way for naming things. They define feature sets and dependencies. This is especially important for
> business people.
>
>> And if we will nit pick -what about gnu classpath ? ;)
>
> Classpath or any other JRE do not apply as an argument here because we always assumed that this a
> OpenJDK/Oracle JRE specific feature. J2SE leaves it up to the JRE vendor on how to implement the
> configuration of the default SecurityManager and default Permissions.

Thats not 100% true. *plugin* is *icedtea* specific feature. Our Javaws implementation  *IS* know to 
work with openjdk, oraclejdk, IBMjdk and (yah..well..)mostly also with GNU classpath.

J.


From emailgrant at gmail.com  Tue Jan 28 05:44:10 2014
From: emailgrant at gmail.com (Grant)
Date: Tue, 28 Jan 2014 05:44:10 -0800
Subject: building icedtea-7 on ARM
In-Reply-To: <1800522928.83487.1390886467315.JavaMail.root@redhat.com>
References: 
	<52CFBD29.4000502@redhat.com>
	
	
	<52D6A58F.7060909@redhat.com> <52D6AC0D.6090905@RedHat.Com>
	
	<1800522928.83487.1390886467315.JavaMail.root@redhat.com>
Message-ID: 

>> >>> Hi Andrew, can you point me in the right direction with this?  Here
>> >>> are a couple errors I'm getting depending on compile options and
>> >>> bootstrap VM:
>> >>>
>> >>> http://pastebin.com/VV3rMezP
>> >>> http://pastebin.com/ThjufjyH
>> >>
>> >> This may be the bug that Chris Philips is working on.
>> >>
>> >> Chris?
>> >>
>> >> Andrew.
>> >>
>> > Neither of these look familiar (though I recollect some issues in the
>> > cryptocheck
>> > for other archs so it may be a generic failure...).
>> > I am planning update the it7-head forest with latest arm32 stuff in near
>> > future so it
>> > might be better to await that event. (Near future ~ a week +/- ).
>> >
>> > Chris
>>
>> Does anyone know where I can check to see if this has been updated?
>>
>> - Grant
>>
>
> http://icedtea.classpath.org/hg/icedtea7-forest/hotspot
>
> Nothing yet. I'll ping this thread when something happens.
> --
> Andrew :)

I thought "Merge jdk7u60-b03" indicated an update 5 days ago?  I
updated all of the tarballs in my local ebuild (except for cacao and
jamvm which don't seem to have changed) and I was planning on
attempting a compile today.

- Grant

From ChrisPhi at redhat.com  Tue Jan 28 06:33:06 2014
From: ChrisPhi at redhat.com (Chris Phillips)
Date: Tue, 28 Jan 2014 09:33:06 -0500
Subject: building icedtea-7 on ARM
In-Reply-To: 
References: 	<52CFBD29.4000502@redhat.com>			<52D6A58F.7060909@redhat.com>	<52D6AC0D.6090905@RedHat.Com>		<1800522928.83487.1390886467315.JavaMail.root@redhat.com>
	
Message-ID: <52E7BFA2.20705@RedHat.Com>

Hi

On 28/01/14 08:44 AM, Grant wrote:
>>>>>> Hi Andrew, can you point me in the right direction with this?  Here
>>>>>> are a couple errors I'm getting depending on compile options and
>>>>>> bootstrap VM:
>>>>>>
>>>>>> http://pastebin.com/VV3rMezP
>>>>>> http://pastebin.com/ThjufjyH
>>>>> This may be the bug that Chris Philips is working on.
>>>>>
>>>>> Chris?
>>>>>
>>>>> Andrew.
>>>>>
>>>> Neither of these look familiar (though I recollect some issues in the
>>>> cryptocheck
>>>> for other archs so it may be a generic failure...).
>>>> I am planning update the it7-head forest with latest arm32 stuff in near
>>>> future so it
>>>> might be better to await that event. (Near future ~ a week +/- ).
>>>>
>>>> Chris
>>> Does anyone know where I can check to see if this has been updated?
>>>
>>> - Grant
>>>
>> http://icedtea.classpath.org/hg/icedtea7-forest/hotspot
>>
>> Nothing yet. I'll ping this thread when something happens.
>> --
>> Andrew :)
> I thought "Merge jdk7u60-b03" indicated an update 5 days ago?  I
> updated all of the tarballs in my local ebuild (except for cacao and
> jamvm which don't seem to have changed) and I was planning on
> attempting a compile today.
>
> - Grant
That's Andrew Hughes normal merge of openjdk into head. The arm stuff
is still old...

Got delayed by a bad cold last week, so later this week if no major issues.

Chris



From jvanek at redhat.com  Tue Jan 28 06:35:47 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Tue, 28 Jan 2014 15:35:47 +0100
Subject: [rfc][icedtea-web] Javadoc, XHTML conformance, and formatting
	cleanup
In-Reply-To: <52E6A58B.6040501@gmx.de>
References: <52E5E3DE.6010307@gmx.de> <52E66B96.70801@redhat.com>
	<52E6A58B.6040501@gmx.de>
Message-ID: <52E7C043.7010302@redhat.com>

On 01/27/2014 07:29 PM, Jacob Wisor wrote:
> On 01/27/2014 03:22 PM, Jiri Vanek wrote:
>> On 01/27/2014 05:43 AM, Jacob Wisor wrote:
>>> Hello,
>>>
>>> The subject says it. I was especially bothered by javadoc throwing @doctag
>>> errors and warnings as
>>> well as its output not being XML conform. Many HTML elements that have
>>> gathered over time in the
>>> source code have not been XHTML conform hence causing javadoc's output also
>>> not being XML conform. I
>>> think this patch could serve as an improvement to the overall quality of the
>>> source code as the
>>> world transitions to strictly XML conforming data. So, the HTML documents
>>> generated by javadoc
>>> should be fully conforming to XML, hence XHTML documents now. Yey! :-)
>>>
>>> Jacob
>>
>>
>> Wou. Thats the patch.
>>
>>
>> Have the generated javadoc passed some check after the improvements?
>
> Nothing in particular than the obvious. Javadoc just does not complain anymore and it still
> compiles. I did not use any external validators.
>
>> If so What it was, I would include it into some tests-javadoc target...
>
> You could do that, or perhaps the developer's IDE would be a better place for it? You know, eg.
> Eclipse has extensive formatting and javadoc features reminding developers of style etc. Anyway, I
> suppose you would have to test for @doctag (fairly easy) and XHTML conformance. Especially the
> latter one could become a problem because the test is probably going to depend on a validator
> library. The W3C has only since recently provided some public web driven validators, so perhaps
> writing the test would be as easy as opening a HttpConnection and posting the javadoc output on a
> per page basis. But then perhaps, some automated build servers may run into problems while not being
> allowed to access the internet... Perhaps you could reuse those Eclipse libraries with adequate
> style configuration? I do not know for sure, but that is what you would have to figure out.

nn :). I hoped for some more tolerant thing as xmllint adapted for xhtml (or better javadoc). I 
wonted to have it  in automated run as make test-xtml (and test return 0/!0)

nvm. It was just idea.


javadoc itself - is far away from  bein perfect xhtml :(	
>
>> Few comments to changes:
>>
>> You are using
>>
>> + * 
>>    * FirefoxPreferencesParser p = new FirefoxPreferencesParser(prefsFile);
>>    * p.parse();
>>    * Map<String,String> prefs = p.getPreferences();
>>    * System.out.println("blink allowed: " + prefs.get("browser.blink_allowed"));
>> - * 

>> + * 
 is just a styling element, giving a hint as how to render enclosed content.  is a meta
> element meaning that the enclosed content is considered some sort of code that could serve as input
> to some parsers or compiles etc.  does not carry any notion about rendering.

fair enough. Thanx.
>
>>   /**
>> - *
>> - * @author jvanek
>> + * @author Jiri
>> Vanek
>>    */
>>
>> Ugh. Author tag is not allowed. Please just remove instead of fix.
>
> Why is that? A lot of classes have @author doctags. It does not denote ownership. It is just a hint
> as to whom to turn for questions about the code in the future.
> If they are absolutely not allowed, well then all other existing @author doctags need to be stripped
> too. And, that's kind of mind boggling.

hmhhm. The oldest classes (original NETX ones) have author and email-to. Since icedtea take cover 
over project, the author and email-to become obsoleted (as distro-pkg-dev is email now)

I would like to remove, just what was in this hunk - me as Author in this class, as I joined the 
team long after icedtea-web was under icedtea.

If you do have some concerns about my arguments here. Please keep this hunk as you wish.

>
>> diff -r efa527f74184
>> netx/net/sourceforge/jnlp/util/logging/ConsoleOutputPaneModel.java
>> --- a/netx/net/sourceforge/jnlp/util/logging/ConsoleOutputPaneModel.java
>> +++ b/netx/net/sourceforge/jnlp/util/logging/ConsoleOutputPaneModel.java
>> @@ -188,8 +188,8 @@
>>               }
>>               String line = (createLine(messageWithHeader));
>>               if (mark) {
>> -                line = line.replaceAll("\n", "
\n");
>> -                line = line.replaceAll("  ", "  ");//small trick, html is
>> reducting row of sapces to single space. This handles it and stimm allow line wrap
>> +                line = line.replaceAll("\n", "
\n");
>> +                line = line.replaceAll("  ", "  ");//small trick, html is
>> reducting row of spaces to single space. This handles it and stimm allow line wrap
>>                   line = line.replaceAll("\t", "    ");
>>
>> This is not possible. Unluckily the java html parser do not survive 
.
>> Please remove this hunk.
>
hhmm. I have just tested. I have not spotted the "strange behavior" which I had during development.
So its probably ok.... Do you mind to add this hunk as separate chnageset?

> That's a drag. :-\ It should definitely accept it. I guess the same applies to some message properties?

message properties are ok.
>
>> After fixing above. Looks ok.
>>
>>
>> Is backport to 1.4 possible? As the cnages are 99% really javadoc related, I do
>> not insists. My motivation  to backport have only one  valaid point - The
>> refactoring is changing  backporting and forwardporting  from automatic level to
>> manual one.  Unless you have something against, do you mind to backport valid
>> parts after  1.4.2 release?
>
> I do know for sure because there is a lot of stuff here that is not in 1.4. But, I will take a look
> at it.

Only what will pass without much issues.

J.


From gnu.andrew at redhat.com  Tue Jan 28 07:16:10 2014
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 28 Jan 2014 10:16:10 -0500 (EST)
Subject: building icedtea-7 on ARM
In-Reply-To: <52E7BFA2.20705@RedHat.Com>
References: 
	
	<52D6A58F.7060909@redhat.com> <52D6AC0D.6090905@RedHat.Com>
	
	<1800522928.83487.1390886467315.JavaMail.root@redhat.com>
	
	<52E7BFA2.20705@RedHat.Com>
Message-ID: <1114262891.423721.1390922170522.JavaMail.root@redhat.com>



----- Original Message -----
> Hi
> 
> On 28/01/14 08:44 AM, Grant wrote:
> >>>>>> Hi Andrew, can you point me in the right direction with this?  Here
> >>>>>> are a couple errors I'm getting depending on compile options and
> >>>>>> bootstrap VM:
> >>>>>>
> >>>>>> http://pastebin.com/VV3rMezP
> >>>>>> http://pastebin.com/ThjufjyH
> >>>>> This may be the bug that Chris Philips is working on.
> >>>>>
> >>>>> Chris?
> >>>>>
> >>>>> Andrew.
> >>>>>
> >>>> Neither of these look familiar (though I recollect some issues in the
> >>>> cryptocheck
> >>>> for other archs so it may be a generic failure...).
> >>>> I am planning update the it7-head forest with latest arm32 stuff in near
> >>>> future so it
> >>>> might be better to await that event. (Near future ~ a week +/- ).
> >>>>
> >>>> Chris
> >>> Does anyone know where I can check to see if this has been updated?
> >>>
> >>> - Grant
> >>>
> >> http://icedtea.classpath.org/hg/icedtea7-forest/hotspot
> >>
> >> Nothing yet. I'll ping this thread when something happens.
> >> --
> >> Andrew :)
> > I thought "Merge jdk7u60-b03" indicated an update 5 days ago?  I
> > updated all of the tarballs in my local ebuild (except for cacao and
> > jamvm which don't seem to have changed) and I was planning on
> > attempting a compile today.
> >
> > - Grant
> That's Andrew Hughes normal merge of openjdk into head. The arm stuff
> is still old...
> 
> Got delayed by a bad cold last week, so later this week if no major issues.
> 
> Chris
> 
> 
> 

Just send me a patch as soon as you can, Chris.

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 andrew at icedtea.classpath.org  Tue Jan 28 07:38:23 2014
From: andrew at icedtea.classpath.org (andrew at icedtea.classpath.org)
Date: Tue, 28 Jan 2014 15:38:23 +0000
Subject: /hg/release/icedtea7-2.4: 2 new changesets
Message-ID: 

changeset 6737b461b59a in /hg/release/icedtea7-2.4
details: http://icedtea.classpath.org/hg/release/icedtea7-2.4?cmd=changeset;node=6737b461b59a
author: Andrew John Hughes 
date: Wed Jan 22 10:46:56 2014 +0000

	Remove bug IDs not in Mercurial repositories.

	2014-01-22  Andrew John Hughes  

		* NEWS: Remove bug IDs not in repository.


changeset ceec45b60d01 in /hg/release/icedtea7-2.4
details: http://icedtea.classpath.org/hg/release/icedtea7-2.4?cmd=changeset;node=ceec45b60d01
author: Andrew John Hughes 
date: Tue Jan 28 15:37:59 2014 +0000

	Bring in non-security changes from u51b31, plus PR1653 & PR1654.

	2014-01-28  Andrew John Hughes  

		* Makefile.am:
		(BUILD_VERSION): Set to b31.
		(CORBA_CHANGESET): Update to IcedTea 2.4 HEAD.
		(JAXP_CHANGESET): Likewise.
		(JAXWS_CHANGESET): Likewise.
		(JDK_CHANGESET): Likewise.
		(LANGTOOLS_CHANGESET): Likewise.
		(OPENJDK_CHANGESET): Likewise.
		(CORBA_SHA256SUM): Likewise.
		(JAXP_SHA256SUM): Likewise.
		(JAXWS_SHA256SUM): Likewise.
		(JDK_SHA256SUM): Likewise.
		(LANGTOOLS_SHA256SUM): Likewise.
		(OPENJDK_SHA256SUM): Likewise.
		* NEWS: Updated.
		* hotspot.map: Update to IcedTea 2.4 HEAD.
		* patches/boot/ecj-diamond.patch: Regenerated.


diffstat:

 ChangeLog                      |    24 +
 Makefile.am                    |    26 +-
 NEWS                           |    38 +-
 hotspot.map                    |     2 +-
 patches/boot/ecj-diamond.patch |  3093 +++++++++++++++++++--------------------
 5 files changed, 1616 insertions(+), 1567 deletions(-)

diffs (truncated from 4936 to 500 lines):

diff -r a41acae0ba85 -r ceec45b60d01 ChangeLog
--- a/ChangeLog	Wed Jan 22 10:08:10 2014 +0000
+++ b/ChangeLog	Tue Jan 28 15:37:59 2014 +0000
@@ -1,3 +1,27 @@
+2014-01-28  Andrew John Hughes  
+
+	* Makefile.am:
+	(BUILD_VERSION): Set to b31.
+	(CORBA_CHANGESET): Update to IcedTea 2.4 HEAD.
+	(JAXP_CHANGESET): Likewise.
+	(JAXWS_CHANGESET): Likewise.
+	(JDK_CHANGESET): Likewise.
+	(LANGTOOLS_CHANGESET): Likewise.
+	(OPENJDK_CHANGESET): Likewise.
+	(CORBA_SHA256SUM): Likewise.
+	(JAXP_SHA256SUM): Likewise.
+	(JAXWS_SHA256SUM): Likewise.
+	(JDK_SHA256SUM): Likewise.
+	(LANGTOOLS_SHA256SUM): Likewise.
+	(OPENJDK_SHA256SUM): Likewise.
+	* NEWS: Updated.
+	* hotspot.map: Update to IcedTea 2.4 HEAD.
+	* patches/boot/ecj-diamond.patch: Regenerated.
+
+2014-01-22  Andrew John Hughes  
+
+	* NEWS: Remove bug IDs not in repository.
+
 2014-01-22  Andrew John Hughes  
 
 	* configure.ac: Bump to 2.4.5pre.
diff -r a41acae0ba85 -r ceec45b60d01 Makefile.am
--- a/Makefile.am	Wed Jan 22 10:08:10 2014 +0000
+++ b/Makefile.am	Tue Jan 28 15:37:59 2014 +0000
@@ -1,22 +1,22 @@
 # Dependencies
 
 JDK_UPDATE_VERSION = 51
-BUILD_VERSION = b00
+BUILD_VERSION = b31
 COMBINED_VERSION = $(JDK_UPDATE_VERSION)-$(BUILD_VERSION)
 
-CORBA_CHANGESET = e540fd592221
-JAXP_CHANGESET = 2e2bf2d8be16
-JAXWS_CHANGESET = 5aceb5a787b1
-JDK_CHANGESET = 1fe539ed00bc
-LANGTOOLS_CHANGESET = 3f5408abf14b
-OPENJDK_CHANGESET = 796d1bf47b24
+CORBA_CHANGESET = 3594dbde270d
+JAXP_CHANGESET = 8fe156ad49e2
+JAXWS_CHANGESET = 32ea8b1ed91a
+JDK_CHANGESET = a74c2e4a756b
+LANGTOOLS_CHANGESET = dabd37b7e295
+OPENJDK_CHANGESET = 410eb7fef869
 
-CORBA_SHA256SUM = 77c3285f6abdefe7f19fc4c698ef1f4fe533f38941314e7e7077c34fa5eb4456
-JAXP_SHA256SUM = 48bb8ece00ef62c6c0161dd90e5789419594dfb5d08163781dac9ffc00c0a3f8
-JAXWS_SHA256SUM = ee2a7165b78693c3bb61a90128b60934704e9a5c6c7514abfbb61e41531b9919
-JDK_SHA256SUM = 16373b85dc5123cfe1816ec04f7d14e9a048c6eee7eb7c22b5b816fa1fd5e9bc
-LANGTOOLS_SHA256SUM = 4375ccfacc49793dd0f13cb73ce3c684218bce71008fc237f3b6da754f4dfea6
-OPENJDK_SHA256SUM = abe048022f46f4d04130b2cf6a1b1d897bdca981518349d34fe5b415310f7782
+CORBA_SHA256SUM = d1f97e143fe94ae3a56b45bb5a90f8ab10ec2be4ff770a788f0a1ac677e27a7d
+JAXP_SHA256SUM = 0a2a40186cedfbeb8f87b0bc86bea2830943943081d4289fc74f7a783b2e1af3
+JAXWS_SHA256SUM = 08a169b6b02883759ec7a412aa91aa3e37480761cb50b95d092dbcdb2fc9a3d0
+JDK_SHA256SUM = 1755a0c0439c7b8e0552ece4e24686ecfd64ef886dea0622e0b9f224103674ae
+LANGTOOLS_SHA256SUM = 86cb370ce2084c4b699d8c002ebe6c026e86206ffa82a2f3d7906aadb94ed79f
+OPENJDK_SHA256SUM = 2de151c7275d91ef082e63fcc0957c5f9290404ec6e20ecfa1e752e16bfab707
 
 CACAO_VERSION = e215e36be9fc
 CACAO_SHA256SUM = 4966514c72ee7ed108b882d9b6e65c3adf8a8f9c2dccb029f971b3c8cb4870ab
diff -r a41acae0ba85 -r ceec45b60d01 NEWS
--- a/NEWS	Wed Jan 22 10:08:10 2014 +0000
+++ b/NEWS	Tue Jan 28 15:37:59 2014 +0000
@@ -14,6 +14,40 @@
 
 New in release 2.4.5 (2014-01-XX):
 
+* Backports
+  - S8015976: OpenJDK part of bug JDK-8015812 [TEST_BUG] Tests have conflicting test descriptions
+  - S8022698: javax/script/GetInterfaceTest.java fails since 7u45 b04 with -agentvm option
+  - S8022868: missing codepage Cp290 at java runtime
+  - S8023310: Thread contention in the method Beans.IsDesignTime()
+  - S8024461: [macosx] Java crashed on mac10.9 for swing and 2d function manual test
+  - S8025679: Increment minor version of HSx for 7u51 and initialize the build number
+  - S8026037: [TESTBUG] sun/security/tools/jarsigner/warnings.sh test fails on Solaris
+  - S8026304: jarsigner output bad grammar
+  - S8026772: test/sun/util/resources/TimeZone/Bug6317929.java failing
+  - S8026887: Make issues due to failed large pages allocations easier to debug
+  - S8027204: Revise the update of 8026204 and 8025758
+  - S8027224: test regression - ClassNotFoundException
+  - S8027370: Support tzdata2013h
+  - S8027378: Two closed/javax/xml/8005432 fails with jdk7u51b04
+  - S8027787: 7u51 l10n resource file translation update 1
+  - S8027837: JDK-8021257 causes CORBA build failure on emdedded platforms
+  - S8027943: serial version of com.sun.corba.se.spi.orbutil.proxy.CompositeInvocationHandlerImpl changed in 7u45
+  - S8027944: Increment hsx 24.51 build to b02 for 7u51-b07
+  - S8028057: Modify jarsigner man page documentation to document CCC 8024302: Clarify jar verifications
+  - S8028090: reverting change - changeset pushed with incorrect commit message, linked to wrong issue
+  - S8028111: XML readers share the same entity expansion counter
+  - S8028215: ORB.init fails with SecurityException if properties select the JDK default ORB
+  - S8028293: Check local configuration for actual ephemeral port range
+  - S8028382: Two javax/xml/8005433 tests still fail after the fix JDK-8028147
+  - S8028453: AsynchronousSocketChannel.connect() requires SocketPermission due to bind to local address (win)
+  - S8028823: java/net/Makefile tabs converted to spaces
+  - S8029038: Revise fix for XML readers share the same entity expansion counter
+  - S8029842: Increment hsx 24.51 build to b03 for 7u51-b11
+* Bug fixes
+  - Fix broken bootstrap build by updating ecj-multicatch.patch
+  - PR1653: Support ppc64le via Zero
+  - PR1654: ppc32 needs a larger ThreadStackSize to build
+
 New in release 2.4.4 (2014-01-14):
 
 * Security fixes
@@ -21,8 +55,8 @@
   - S7068126, CVE-2014-0373: Enhance SNMP statuses
   - S8010935: Better XML handling
   - S8011786, CVE-2014-0368: Better applet networking
-  - S8021257, S8025022, CVE-2013-5896 : com.sun.corba.se.** should be on restricted package list
-  - S8021271, S8021266, CVE-2014-0408: Better buffering in ObjC code
+  - S8021257, CVE-2013-5896: com.sun.corba.se.** should be on restricted package list
+  - S8021271, CVE-2014-0408: Better buffering in ObjC code
   - S8022904: Enhance JDBC Parsers
   - S8022927: Input validation for byte/endian conversions
   - S8022935: Enhance Apache resolver classes
diff -r a41acae0ba85 -r ceec45b60d01 hotspot.map
--- a/hotspot.map	Wed Jan 22 10:08:10 2014 +0000
+++ b/hotspot.map	Tue Jan 28 15:37:59 2014 +0000
@@ -1,2 +1,2 @@
 # version url changeset sha256sum
-default http://icedtea.classpath.org/hg/release/icedtea7-forest-2.4/hotspot a8a33cc2dd4b cb5f109ae32c07301bc3a017c334ca3a7723124ff217d46127a16ade516d2902
+default http://icedtea.classpath.org/hg/release/icedtea7-forest-2.4/hotspot cbeecad5efcb 511d0337cf8ab6cfbd9b7d9a5a2dd2a19bad01eb11b33e947154b95ddb46ab0e
diff -r a41acae0ba85 -r ceec45b60d01 patches/boot/ecj-diamond.patch
--- a/patches/boot/ecj-diamond.patch	Wed Jan 22 10:08:10 2014 +0000
+++ b/patches/boot/ecj-diamond.patch	Tue Jan 28 15:37:59 2014 +0000
@@ -1,6 +1,6 @@
 diff -Nru openjdk-boot.orig/corba/src/share/classes/com/sun/corba/se/impl/encoding/CachedCodeBase.java openjdk-boot/corba/src/share/classes/com/sun/corba/se/impl/encoding/CachedCodeBase.java
---- openjdk-boot.orig/corba/src/share/classes/com/sun/corba/se/impl/encoding/CachedCodeBase.java	2013-07-24 21:31:42.000000000 +0100
-+++ openjdk-boot/corba/src/share/classes/com/sun/corba/se/impl/encoding/CachedCodeBase.java	2013-07-30 18:32:50.125579213 +0100
+--- openjdk-boot.orig/corba/src/share/classes/com/sun/corba/se/impl/encoding/CachedCodeBase.java	2014-01-23 23:19:18.000000000 +0000
++++ openjdk-boot/corba/src/share/classes/com/sun/corba/se/impl/encoding/CachedCodeBase.java	2014-01-28 11:39:19.697588883 +0000
 @@ -58,7 +58,7 @@
      private CorbaConnection conn;
  
@@ -11,8 +11,8 @@
      public static synchronized void cleanCache( ORB orb ) {
          synchronized (iorMapLock) {
 diff -Nru openjdk-boot.orig/corba/src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java openjdk-boot/corba/src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java
---- openjdk-boot.orig/corba/src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java	2013-07-24 21:31:42.000000000 +0100
-+++ openjdk-boot/corba/src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java	2013-07-30 18:32:50.141579926 +0100
+--- openjdk-boot.orig/corba/src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java	2014-01-23 23:19:18.000000000 +0000
++++ openjdk-boot/corba/src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java	2014-01-28 11:39:19.697588883 +0000
 @@ -1315,7 +1315,7 @@
      protected void shutdownServants(boolean wait_for_completion) {
          Set oaset;
@@ -23,8 +23,8 @@
  
          for (ObjectAdapterFactory oaf : oaset)
 diff -Nru openjdk-boot.orig/corba/src/share/classes/com/sun/corba/se/impl/orbutil/threadpool/ThreadPoolImpl.java openjdk-boot/corba/src/share/classes/com/sun/corba/se/impl/orbutil/threadpool/ThreadPoolImpl.java
---- openjdk-boot.orig/corba/src/share/classes/com/sun/corba/se/impl/orbutil/threadpool/ThreadPoolImpl.java	2013-07-24 21:31:42.000000000 +0100
-+++ openjdk-boot/corba/src/share/classes/com/sun/corba/se/impl/orbutil/threadpool/ThreadPoolImpl.java	2013-07-30 18:32:50.145580045 +0100
+--- openjdk-boot.orig/corba/src/share/classes/com/sun/corba/se/impl/orbutil/threadpool/ThreadPoolImpl.java	2014-01-23 23:19:18.000000000 +0000
++++ openjdk-boot/corba/src/share/classes/com/sun/corba/se/impl/orbutil/threadpool/ThreadPoolImpl.java	2014-01-28 11:39:19.697588883 +0000
 @@ -108,7 +108,7 @@
      private ThreadGroup threadGroup;
  
@@ -44,8 +44,8 @@
  
          for (WorkerThread wt : copy) {
 diff -Nru openjdk-boot.orig/jaxp/src/com/sun/org/apache/xml/internal/serializer/Encodings.java openjdk-boot/jaxp/src/com/sun/org/apache/xml/internal/serializer/Encodings.java
---- openjdk-boot.orig/jaxp/src/com/sun/org/apache/xml/internal/serializer/Encodings.java	2013-07-12 17:07:55.970380942 +0100
-+++ openjdk-boot/jaxp/src/com/sun/org/apache/xml/internal/serializer/Encodings.java	2013-07-12 17:07:29.097954416 +0100
+--- openjdk-boot.orig/jaxp/src/com/sun/org/apache/xml/internal/serializer/Encodings.java	2014-01-28 11:38:19.384649230 +0000
++++ openjdk-boot/jaxp/src/com/sun/org/apache/xml/internal/serializer/Encodings.java	2014-01-28 11:39:19.697588883 +0000
 @@ -297,8 +297,8 @@
      //
      private final static class EncodingInfos {
@@ -66,26 +66,9 @@
                  while (keys.hasMoreElements()) {
                      final String javaName = (String) keys.nextElement();
                      final String[] mimes = parseMimeTypes(props.getProperty(javaName));
-diff -Nru openjdk-boot.orig/jdk/src/share/classes/com/sun/beans/decoder/DocumentHandler.java openjdk-boot/jdk/src/share/classes/com/sun/beans/decoder/DocumentHandler.java
---- openjdk-boot.orig/jdk/src/share/classes/com/sun/beans/decoder/DocumentHandler.java	2013-07-24 21:32:02.000000000 +0100
-+++ openjdk-boot/jdk/src/share/classes/com/sun/beans/decoder/DocumentHandler.java	2013-07-30 18:32:50.149580081 +0100
-@@ -62,9 +62,10 @@
-  */
- public final class DocumentHandler extends DefaultHandler {
-     private final AccessControlContext acc = AccessController.getContext();
--    private final Map> handlers = new HashMap<>();
--    private final Map environment = new HashMap<>();
--    private final List