From Vladislav.Karnaukhov at oracle.com  Mon Jun  3 09:39:53 2013
From: Vladislav.Karnaukhov at oracle.com (Vladislav Karnaukhov)
Date: Mon, 03 Jun 2013 20:39:53 +0400
Subject: <AWT Dev> [7uX] Review request for 8010721: In JDK7 the menu
	bar disappears when a Dialog is shown
In-Reply-To: <515058BF.9090703@oracle.com>
References: <515058BF.9090703@oracle.com>
Message-ID: <51ACC6D9.8080200@oracle.com>

Hello,

could you please review a backport of the fix for 8010721?

bug: http://bugs.sun.com/view_bug.do?bug_id=8010721
webrev: http://cr.openjdk.java.net/~vkarnauk/8010721/jdk7/webrev.01/
jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c36626831f07
mail: http://mail.openjdk.java.net/pipermail/awt-dev/2013-April/004521.html

Please note that I accidentally used previous version of the fix for 
jdk8 push (i.e. version 02 instead of 03). The bug 8015425 is created to 
push additional changes into jdk8, and won't be backported into jdk7.

jdk7 version uses correct fix version.

Regards,
- Vlad

From anthony.petrov at oracle.com  Tue Jun  4 02:28:38 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Tue, 04 Jun 2013 13:28:38 +0400
Subject: <AWT Dev> [7uX] Review request for 8010721: In JDK7 the menu
	bar disappears when a Dialog is shown
In-Reply-To: <51ACC6D9.8080200@oracle.com>
References: <515058BF.9090703@oracle.com> <51ACC6D9.8080200@oracle.com>
Message-ID: <51ADB346.5050303@oracle.com>

Hi Vladislav,

Thanks for noticing the problem with missing changes in JDK8.

The backport to 7u looks good to me.

--
best regards,
Anthony

On 06/03/2013 08:39 PM, Vladislav Karnaukhov wrote:
> Hello,
>
> could you please review a backport of the fix for 8010721?
>
> bug: http://bugs.sun.com/view_bug.do?bug_id=8010721
> webrev: http://cr.openjdk.java.net/~vkarnauk/8010721/jdk7/webrev.01/
> jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c36626831f07
> mail: http://mail.openjdk.java.net/pipermail/awt-dev/2013-April/004521.html
>
> Please note that I accidentally used previous version of the fix for
> jdk8 push (i.e. version 02 instead of 03). The bug 8015425 is created to
> push additional changes into jdk8, and won't be backported into jdk7.
>
> jdk7 version uses correct fix version.
>
> Regards,
> - Vlad

From Vladislav.Karnaukhov at oracle.com  Wed Jun  5 03:59:20 2013
From: Vladislav.Karnaukhov at oracle.com (Vladislav Karnaukhov)
Date: Wed, 05 Jun 2013 14:59:20 +0400
Subject: <AWT Dev> [8] Request for review 8015425: A follow-up for the fix
	8010721
Message-ID: <51AF1A08.90102@oracle.com>

Hello,

could you please review the fix for 8015425?

bug: http://bugs.sun.com/view_bug.do?bug_id=8015425
webrev: http://cr.openjdk.java.net/~vkarnauk/8015425/webrev.00/

During the push of 8010721 into jdk8, I accidentally used webrev version 
02 instead of 03. This fix contains missed bits of code; it's trivial 
and just inserts a missing 'if' statement.

This is for jdk8 only.

Regards,
- Vlad

From anthony.petrov at oracle.com  Wed Jun  5 04:22:17 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 05 Jun 2013 15:22:17 +0400
Subject: <AWT Dev> [8] Request for review 8015425: A follow-up for the
	fix 8010721
In-Reply-To: <51AF1A08.90102@oracle.com>
References: <51AF1A08.90102@oracle.com>
Message-ID: <51AF1F69.2090307@oracle.com>

Looks fine.

--
best regards,
Anthony

On 06/05/2013 02:59 PM, Vladislav Karnaukhov wrote:
> Hello,
>
> could you please review the fix for 8015425?
>
> bug: http://bugs.sun.com/view_bug.do?bug_id=8015425
> webrev: http://cr.openjdk.java.net/~vkarnauk/8015425/webrev.00/
>
> During the push of 8010721 into jdk8, I accidentally used webrev version
> 02 instead of 03. This fix contains missed bits of code; it's trivial
> and just inserts a missing 'if' statement.
>
> This is for jdk8 only.
>
> Regards,
> - Vlad

From Sergey.Bylokhov at oracle.com  Wed Jun  5 05:13:44 2013
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 5 Jun 2013 05:13:44 -0700 (PDT)
Subject: <AWT Dev> [8] Request for review 8015425: A follow-up for the fix
	8010721
In-Reply-To: <51AF1A08.90102@oracle.com>
References: <51AF1A08.90102@oracle.com>
Message-ID: <51AF2B78.7060400@oracle.com>

HI, Vladislav.
Fix looks good.

On 05.06.2013 14:59, Vladislav Karnaukhov wrote:
> Hello,
>
> could you please review the fix for 8015425?
>
> bug: http://bugs.sun.com/view_bug.do?bug_id=8015425
> webrev: http://cr.openjdk.java.net/~vkarnauk/8015425/webrev.00/
>
> During the push of 8010721 into jdk8, I accidentally used webrev 
> version 02 instead of 03. This fix contains missed bits of code; it's 
> trivial and just inserts a missing 'if' statement.
>
> This is for jdk8 only.
>
> Regards,
> - Vlad


-- 
Best regards, Sergey.


From david.dehaven at oracle.com  Wed Jun  5 09:26:19 2013
From: david.dehaven at oracle.com (David DeHaven)
Date: Wed, 5 Jun 2013 09:26:19 -0700 (PDT)
Subject: [7u40] Request for review: [macosx] jawt_md.h shipped with jdk is
	outdated
In-Reply-To: <51A4E16F.9070309@oracle.com>
References: <A7FB82B3-E008-490D-9F2E-163065EAA5ED@oracle.com>
	<5196169F.1020505@oracle.com>
	<1989FC2E-F5D9-4983-8429-A4D915FFB07E@oracle.com>
	<5196415A.7020807@oracle.com>
	<E97BB6DE-0114-4DFD-A87F-F78B112B53B5@oracle.com>
	<5196483D.4040106@oracle.com>
	<B7B5CFE3-F041-47D5-BC4D-D2F70CFE37C9@oracle.com>
	<D82D1F0A-BCA7-4626-892A-15E0713109BD@oracle.com>
	<51A4E16F.9070309@oracle.com>
Message-ID: <37DEA186-6DFF-41AF-8926-A55BF08DCA7F@oracle.com>


I managed to scrape a few seconds together, I'll post this on 7u-dev as we're getting down to the wire for 7u40.

-DrD-

> Yes, you need a jdk7u-dev@ approval before this can be pushed to 7u-dev.
> 
> I can push your fix tomorrow (provided you get the approval by then). But AFAIK, nobody but me has reviewed it yet.
> 
> Can we get at least one more review please?
> 
> http://cr.openjdk.java.net/~ddehaven/7181710/jdk.0/
> 
> --
> best regards,
> Anthony
> 
> On 05/28/2013 07:16 PM, David DeHaven wrote:
>> 
>> Should I post this to 7u-dev for approval? Can I get someone to sponsor this (since I'm not a committer...)?
>> 
>> -DrD-
>> 
>>> 
>>> Incidentally, I tried compiling with the JDK8 jni_md.h and it built fine... I didn't think the related changes were backported, or were they?
>>> 
>>> Either way, I think it needs to be a separate issue. Not that it matters, I'm off chasing fires with buckets of gasoline again... :(
>>> 
>>> -DrD-
>>> 
>>>> Thanks. I'm OK if this will be a separate bug.
>>>> 
>>>> --
>>>> best regards,
>>>> Anthony
>>>> 
>>>> On 05/17/2013 07:00 PM, David DeHaven wrote:
>>>>> 
>>>>>>>> The fix looks good to me. Only one question:
>>>>>>>> 
>>>>>>>> src/macosx/javavm/export/jni_md.h
>>>>>>>>> 29 #define JNIEXPORT
>>>>>>>> 
>>>>>>>> Does the empty #define imply that when building a jni lib on Mac, it should export all of its symbols by default?
>>>>>>> 
>>>>>>> It depends on gcc's visibility setting, but yes, by default all symbols are exported.
>>>>>>> 
>>>>>>> JDK8 has a better jni_md.h that sets JNIEXPORT to __attribute__(visibility(("default"))). That change should be backported, but should probably need to be done under a different bug ID. I suppose I could sneak it in here :)
>>>>>> 
>>>>>> IIRC, Martin Buchholz's fix only updated the jni_md.h for Solaris, so the Mac's one is unlikely to change even if his fix is back-ported. Hence I'd vote for adding the __attribute__(visibility(("default"))) in your fix (unless this can break anything - recall the changes needed in awt_LoadLibrary.c where the JNIEXPORT was used in a typedef).
>>>>> 
>>>>> The Mac builds currently use the solaris headers in both versions (which is why I was so interested in helping him). I haven't tried building 7u-dev with the attribute set yet, so I'm not sure of the consequences in JDK7. I can give it a try, if it's too ugly I'll file a separate issue to do the backport.
>>>>> 
>>>>> 
>>>>>> Also, I assume you're going to forward-port your fix to JDK 8 at some point?
>>>>> 
>>>>> Yes, that's my plan.
>>>>> 
>>>>> -DrD-
>>>>> 
>>> 
>> 


From nmrview at me.com  Fri Jun  7 05:43:07 2013
From: nmrview at me.com (Bruce Johnson)
Date: Fri, 07 Jun 2013 08:43:07 -0400
Subject: Status of bug 8007267 setDefaultMenuBar on MacOS X
In-Reply-To: <mailman.1.1369422000.28237.macosx-port-dev@openjdk.java.net>
References: <mailman.1.1369422000.28237.macosx-port-dev@openjdk.java.net>
Message-ID: <520368DC-F174-4611-BE2D-28B0BA68368C@me.com>

8007267 : [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working


Is there any estimate of when this bug will be resolved.  I keep seeing comments that we should migrate our Mac applications to Java 7, but it seems that any Java applications with multiple windows that share a common screen menu bar (like my own)  really need this.

Thanks for any information,

Bruce



From Koen.VanDenBorre at esko.com  Tue Jun 11 05:47:47 2013
From: Koen.VanDenBorre at esko.com (Van Den Borre, Koen)
Date: Tue, 11 Jun 2013 12:47:47 +0000
Subject: [macosx] JTableHeader painting error with Java 8 on Mac
Message-ID: <02623B53-A31D-4ED6-AAAB-F4896A6FD56D@esko.com>

Hi,

I noticed that on Java 8 on Mac, the JTableHeader looks clipped (the bottom line is not visible).
This was not an issue in Java 6.

Here is a simple test case:

import javax.swing.JFrame;
import javax.swing.JScrollPane;
import javax.swing.JTable;
import javax.swing.SwingUtilities;

public class JTableHeaderTest
{
	public void run()
	{
		JTable table = new JTable(2, 5);
		
		JScrollPane scrollableTable = new JScrollPane(table);
		
		JFrame frame = new JFrame();
		frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
		frame.getContentPane().add(scrollableTable);
		frame.setSize(300, 300);
		frame.setLocationRelativeTo(null);
		frame.setVisible(true);
	}

	public static void main(String[] arguments)
	{
		SwingUtilities.invokeLater(new Runnable()
		{
			@Override
			public void run()
			{
				JTableHeaderTest test = new JTableHeaderTest();
				test.run();
			}
		});
	}
}

From Abhinay.Reddyreddy at mathworks.com  Tue Jun 11 10:00:41 2013
From: Abhinay.Reddyreddy at mathworks.com (Abhinay Reddyreddy)
Date: Tue, 11 Jun 2013 17:00:41 +0000
Subject: [macosx] Printing unicode chars with drawGlyphVector in Java 7.
Message-ID: <CDDCCFF7.4672%Abhinay.Reddyreddy@mathworks.com>

Hi,

I found that drawGlyphVector method does not work properly for printing unicode characters (at-least Japanese), when used with NATIVE print dialogs  on Mac OS X.
Changing the locale of the machine did not make any difference. I verified this used to work fine with Java 6.

Here's a test case and the attachment shows a picture of the

import java.awt.*;
import javax.swing.*;
import java.awt.print.*;
import javax.print.attribute.*;
import javax.print.attribute.standard.*;
import java.awt.font.*;

public class PrintUnicodeTest implements Printable
{
public static int count = 0;
    public void startTestCase()
    {
    PrinterJob pj = PrinterJob.getPrinterJob();
        PrintRequestAttributeSet pras  = new HashPrintRequestAttributeSet();
        pras.add(DialogTypeSelection.NATIVE);
        pj.setPrintable(this);
        if (pj.printDialog(pras))
        {
            try{
                pj.print(pras);
            } catch (Exception e)  { }
        }
    }

    public int print(Graphics g, PageFormat pf, int pageNo) throws PrinterException
    {
        Graphics2D g2d = (Graphics2D)g;
        if(pageNo > 0)
            return Printable.NO_SUCH_PAGE;
        else {
            g2d.setColor(Color.blue);
            Font fnt = new Font("Serif", Font.PLAIN, 24);
            g2d.setFont(fnt);
            String s = "?????y.m";
            int x = 100, y = 100;
            GlyphVector glyphVec = g2d.getFont().createGlyphVector( g2d.getFontRenderContext(), "using shape fill: "+s);
            g2d.setRenderingHint(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON);
            // extract glyph shapes and draw ?V this works fine.
            Shape shape = glyphVec.getOutline();
            g2d.translate(x, y);
            g2d.fill(shape);
            g2d.translate(-x, -y);
            // use in-built drawString method ?V this does not work because of bug 7183516
            g.drawString("using drawString (sun Bug#7183516): "+s, x, y*2);
            // use in-built drawGlyphVector method ?V this the bug I am reporting.
            GlyphVector glyphVec2 = g2d.getFont().createGlyphVector( g2d.getFontRenderContext(), "using drawGlyphVector: "+s);
            g2d.drawGlyphVector(glyphVec2, (float)x, (float)y*3);
            return Printable.PAGE_EXISTS;
        }
    }

   public static void main (String []Args) {
      PrintUnicodeTest st = new PrintUnicodeTest ();
      st.startTestCase ();
   }
}

I have submitted a bug(9003977). Let me know if anyone had luck printing non-english/roman characters with the native print dialog on Mac OS X.

Thanks,
Abhinay.

From alexandr.scherbatiy at oracle.com  Thu Jun 13 04:54:26 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 13 Jun 2013 15:54:26 +0400
Subject: [macosx] JTableHeader painting error with Java 8 on Mac
In-Reply-To: <02623B53-A31D-4ED6-AAAB-F4896A6FD56D@esko.com>
References: <02623B53-A31D-4ED6-AAAB-F4896A6FD56D@esko.com>
Message-ID: <51B9B2F2.2000805@oracle.com>

On 6/11/2013 4:47 PM, Van Den Borre, Koen wrote:
> Hi,
>
> I noticed that on Java 8 on Mac, the JTableHeader looks clipped (the bottom line is not visible).
> This was not an issue in Java 6.

     It seems that there should be newHeight + 1 for the border painting:
http://hg.openjdk.java.net/jdk8/awt/jdk/file/a7d943998bd3/src/macosx/classes/com/apple/laf/AquaTableHeaderBorder.java

       102         final int newX = x;
       103         final int newY = y;
       104         final int newWidth = width;
       105         final int newHeight = height;
       106
       107         painter.paint(g, c, newX - 1, newY - 1, newWidth + 1, 
newHeight);

    This is  a good chance for the JDK 8 patch contribution.

  Thanks,
  Alexandr.

>
> Here is a simple test case:
>
> import javax.swing.JFrame;
> import javax.swing.JScrollPane;
> import javax.swing.JTable;
> import javax.swing.SwingUtilities;
>
> public class JTableHeaderTest
> {
> 	public void run()
> 	{
> 		JTable table = new JTable(2, 5);
> 		
> 		JScrollPane scrollableTable = new JScrollPane(table);
> 		
> 		JFrame frame = new JFrame();
> 		frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
> 		frame.getContentPane().add(scrollableTable);
> 		frame.setSize(300, 300);
> 		frame.setLocationRelativeTo(null);
> 		frame.setVisible(true);
> 	}
>
> 	public static void main(String[] arguments)
> 	{
> 		SwingUtilities.invokeLater(new Runnable()
> 		{
> 			@Override
> 			public void run()
> 			{
> 				JTableHeaderTest test = new JTableHeaderTest();
> 				test.run();
> 			}
> 		});
> 	}
> }


From alexandr.scherbatiy at oracle.com  Thu Jun 13 05:26:14 2013
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 13 Jun 2013 16:26:14 +0400
Subject: [macosx] JTableHeader painting error with Java 8 on Mac
In-Reply-To: <51B9B2F2.2000805@oracle.com>
References: <02623B53-A31D-4ED6-AAAB-F4896A6FD56D@esko.com>
	<51B9B2F2.2000805@oracle.com>
Message-ID: <51B9BA66.2080809@oracle.com>

On 6/13/2013 3:54 PM, Alexander Scherbatiy wrote:
> On 6/11/2013 4:47 PM, Van Den Borre, Koen wrote:
>> Hi,
>>
>> I noticed that on Java 8 on Mac, the JTableHeader looks clipped (the 
>> bottom line is not visible).
>> This was not an issue in Java 6.
>
>     It seems that there should be newHeight + 1 for the border painting:
> http://hg.openjdk.java.net/jdk8/awt/jdk/file/a7d943998bd3/src/macosx/classes/com/apple/laf/AquaTableHeaderBorder.java 
>
>
>       102         final int newX = x;
>       103         final int newY = y;
>       104         final int newWidth = width;
>       105         final int newHeight = height;
>       106
>       107         painter.paint(g, c, newX - 1, newY - 1, newWidth + 
> 1, newHeight);
>
>    This is  a good chance for the JDK 8 patch contribution.

    I have created the issue 8016524 [macosx] Bottom line is not visible 
for JTableHeader
          http://bugs.sun.com/view_bug.do?bug_id=8016524

     It should be public available soon.

     Thanks,
     Alexandr.
>
>  Thanks,
>  Alexandr.
>
>>
>> Here is a simple test case:
>>
>> import javax.swing.JFrame;
>> import javax.swing.JScrollPane;
>> import javax.swing.JTable;
>> import javax.swing.SwingUtilities;
>>
>> public class JTableHeaderTest
>> {
>>     public void run()
>>     {
>>         JTable table = new JTable(2, 5);
>>
>>         JScrollPane scrollableTable = new JScrollPane(table);
>>
>>         JFrame frame = new JFrame();
>>         frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>         frame.getContentPane().add(scrollableTable);
>>         frame.setSize(300, 300);
>>         frame.setLocationRelativeTo(null);
>>         frame.setVisible(true);
>>     }
>>
>>     public static void main(String[] arguments)
>>     {
>>         SwingUtilities.invokeLater(new Runnable()
>>         {
>>             @Override
>>             public void run()
>>             {
>>                 JTableHeaderTest test = new JTableHeaderTest();
>>                 test.run();
>>             }
>>         });
>>     }
>> }
>


From Arfst.Braren at heidelberg.com  Wed Jun 19 06:14:14 2013
From: Arfst.Braren at heidelberg.com (Braren, Arfst PT-RD23)
Date: Wed, 19 Jun 2013 15:14:14 +0200
Subject: InstallAnywhere problems after Java for OS X 2013-004 Update
Message-ID: <CDE77B46.10326%Arfst.Braren@heidelberg.com>

We have trouble with our InstallerApps based on InstallAnywhere after the latest Updates.


Java for OS X 2013-004 seems to be the "troublemaker".


Any hints?


Kind regards

Arfst Braren

________________________________
Confidentiality note:
The information in this email and any attachment may contain confidential and proprietary information of Heidelberger Druckmaschinen AG and/or its affiliates and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may cause liability. In case you have received this message due to an error in transmission, we kindly ask you to notify the sender immediately and to delete this email and any attachment from your system.

From steve.coy at me.com  Thu Jun 20 05:52:43 2013
From: steve.coy at me.com (Stephen Coy)
Date: Thu, 20 Jun 2013 22:52:43 +1000
Subject: InstallAnywhere problems after Java for OS X 2013-004 Update
In-Reply-To: <CDE77B46.10326%Arfst.Braren@heidelberg.com>
References: <CDE77B46.10326%Arfst.Braren@heidelberg.com>
Message-ID: <C9B8D8E9-6D3A-4724-A862-02BB96A90817@me.com>

This Java release from Apple is generating a lot of dis-satisfied noises over on java-dev at lists.apple.com.

You're not alone?

On 19/06/2013, at 11:14 PM, "Braren, Arfst PT-RD23" <Arfst.Braren at heidelberg.com> wrote:

> We have trouble with our InstallerApps based on InstallAnywhere after the latest Updates.
> 
> 
> Java for OS X 2013-004 seems to be the "troublemaker".
> 
> 
> Any hints?
> 
> 
> Kind regards
> 
> Arfst Braren
> 
> ________________________________
> Confidentiality note:
> The information in this email and any attachment may contain confidential and proprietary information of Heidelberger Druckmaschinen AG and/or its affiliates and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may cause liability. In case you have received this message due to an error in transmission, we kindly ask you to notify the sender immediately and to delete this email and any attachment from your system.


From swingler at apple.com  Fri Jun 21 11:29:08 2013
From: swingler at apple.com (Mike Swingler)
Date: Fri, 21 Jun 2013 11:29:08 -0700
Subject: InstallAnywhere problems after Java for OS X 2013-004 Update
In-Reply-To: <C9B8D8E9-6D3A-4724-A862-02BB96A90817@me.com>
References: <CDE77B46.10326%Arfst.Braren@heidelberg.com>
	<C9B8D8E9-6D3A-4724-A862-02BB96A90817@me.com>
Message-ID: <ADCDB86B-FFCC-4E9C-9458-5EBC92E3F221@apple.com>

We believe that we have addressed the issue:
<http://lists.apple.com/archives/java-dev/2013/Jun/msg00055.html>

Regards,
Mike Swingler
Apple Inc.

On Jun 20, 2013, at 5:52 AM, Stephen Coy <steve.coy at me.com> wrote:

> This Java release from Apple is generating a lot of dis-satisfied noises over on java-dev at lists.apple.com.
> 
> You're not alone?
> 
> On 19/06/2013, at 11:14 PM, "Braren, Arfst PT-RD23" <Arfst.Braren at heidelberg.com> wrote:
> 
>> We have trouble with our InstallerApps based on InstallAnywhere after the latest Updates.
>> 
>> 
>> Java for OS X 2013-004 seems to be the "troublemaker".
>> 
>> 
>> Any hints?
>> 
>> 
>> Kind regards
>> 
>> Arfst Braren


From stevek at stevek.com  Fri Jun 21 12:15:37 2013
From: stevek at stevek.com (Steve Kann)
Date: Fri, 21 Jun 2013 12:15:37 -0700
Subject: AppContext issue in Apple Java 6 -- same issue in Oracle Java 7?
In-Reply-To: <mailman.1.1371841200.4071.macosx-port-dev@openjdk.java.net>
References: <mailman.1.1371841200.4071.macosx-port-dev@openjdk.java.net>
Message-ID: <7229AAB3-3AEF-4F25-9E52-9530CA64486E@stevek.com>


Mike and Mac Java folks,

	First -- Mike -- thank you and Apple for so quickly fixing the Java 6 update!

	We've been experiencing similar issues with Java 7 -- specifically with webstart apps, but it seems that many others are seeing the same thing:

(here's my little list of links, some to Java 6, some to Java 7, with fallout):
http://scn.sap.com/message/14139064

http://knowledgebase.pearsonschool.com/kmp/article/AA-07056

http://www.mathworks.us/matlabcentral/answers/79489-java-1-6-0_51-breaks-matlab-2012b-and-below
http://www.geneious.com/web/geneious/news/-/blogs/java-update-for-geneious-mac

http://www.vassalengine.org/forum/viewtopic.php?f=3&t=6399&sid=4ff99c4e849a62b2ae745a0ad9d5afb6&start=15

http://blog.traderdealer.com.au/2013/06/21/latest-java-update-fix/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+onlinestockmarkettradingupdate+(Trader+Dealer+Blog)

http://www.extensis.com/support/knowledge-base/java-update-1-6-0_51-causes-startup-problems-with-uts-and-portfolio-server-on-mac-os-10-6-and-10-7/
  

	Does anyone know:

	- If this problem is also the problem which has been hosing Java 7u25?
	- If OpenJDK will be picking up a fix?
	- If Oracle will be releasing a fix?

Especially since on 10.7/10.8 Apple is now requiring 7u25 or later, it's hard to ask users to rollback to 7u21.

Thanks.

-SteveK



> Message: 1
> Date: Fri, 21 Jun 2013 11:29:08 -0700
> From: Mike Swingler <swingler at apple.com>
> Subject: Re: InstallAnywhere problems after Java for OS X 2013-004
> 	Update
> To: Stephen Coy <steve.coy at me.com>
> Cc: "Braren, Arfst PT-RD23" <Arfst.Braren at heidelberg.com>,
> 	"macosx-port-dev at openjdk.java.net" <macosx-port-dev at openjdk.java.net>
> Message-ID: <ADCDB86B-FFCC-4E9C-9458-5EBC92E3F221 at apple.com>
> Content-Type: text/plain; charset=windows-1252
> 
> We believe that we have addressed the issue:
> <http://lists.apple.com/archives/java-dev/2013/Jun/msg00055.html>
> 
> Regards,
> Mike Swingler
> Apple Inc.
> 
> On Jun 20, 2013, at 5:52 AM, Stephen Coy <steve.coy at me.com> wrote:
> 
>> This Java release from Apple is generating a lot of dis-satisfied noises over on java-dev at lists.apple.com.
>> 
>> You're not alone?
>> 
>> On 19/06/2013, at 11:14 PM, "Braren, Arfst PT-RD23" <Arfst.Braren at heidelberg.com> wrote:
>> 
>>> We have trouble with our InstallerApps based on InstallAnywhere after the latest Updates.
>>> 
>>> 
>>> Java for OS X 2013-004 seems to be the "troublemaker".
>>> 
>>> 
>>> Any hints?
>>> 
>>> 
>>> Kind regards
>>> 
>>> Arfst Braren
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> macosx-port-dev mailing list
> macosx-port-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/macosx-port-dev
> 
> 
> End of macosx-port-dev Digest, Vol 30, Issue 9
> **********************************************


From leonid.romanov at oracle.com  Fri Jun 21 12:53:22 2013
From: leonid.romanov at oracle.com (Leonid Romanov)
Date: Fri, 21 Jun 2013 23:53:22 +0400
Subject: AppContext issue in Apple Java 6 -- same issue in Oracle Java 7?
In-Reply-To: <7229AAB3-3AEF-4F25-9E52-9530CA64486E@stevek.com>
References: <mailman.1.1371841200.4071.macosx-port-dev@openjdk.java.net>
	<7229AAB3-3AEF-4F25-9E52-9530CA64486E@stevek.com>
Message-ID: <E34C1EA4-8407-4005-ABFE-43D77A539C88@oracle.com>

Hi,
Thanks for the links. I've skimmed through them and it looks like most of them are about Apple Java. There are one or two links where people are reporting 7u25 causing troubles, however, there is not enough evidence to conclude that it is the same problem as with Apple Java.

On Jun 21, 2013, at 11:15 PM, Steve Kann <stevek at stevek.com> wrote:

> 
> Mike and Mac Java folks,
> 
> 	First -- Mike -- thank you and Apple for so quickly fixing the Java 6 update!
> 
> 	We've been experiencing similar issues with Java 7 -- specifically with webstart apps, but it seems that many others are seeing the same thing:
> 
> (here's my little list of links, some to Java 6, some to Java 7, with fallout):
> http://scn.sap.com/message/14139064
> 
> http://knowledgebase.pearsonschool.com/kmp/article/AA-07056
> 
> http://www.mathworks.us/matlabcentral/answers/79489-java-1-6-0_51-breaks-matlab-2012b-and-below
> http://www.geneious.com/web/geneious/news/-/blogs/java-update-for-geneious-mac
> 
> http://www.vassalengine.org/forum/viewtopic.php?f=3&t=6399&sid=4ff99c4e849a62b2ae745a0ad9d5afb6&start=15
> 
> http://blog.traderdealer.com.au/2013/06/21/latest-java-update-fix/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+onlinestockmarkettradingupdate+(Trader+Dealer+Blog)
> 
> http://www.extensis.com/support/knowledge-base/java-update-1-6-0_51-causes-startup-problems-with-uts-and-portfolio-server-on-mac-os-10-6-and-10-7/
> 
> 
> 	Does anyone know:
> 
> 	- If this problem is also the problem which has been hosing Java 7u25?
> 	- If OpenJDK will be picking up a fix?
> 	- If Oracle will be releasing a fix?
> 
> Especially since on 10.7/10.8 Apple is now requiring 7u25 or later, it's hard to ask users to rollback to 7u21.
> 
> Thanks.
> 
> -SteveK
> 
> 
> 
>> Message: 1
>> Date: Fri, 21 Jun 2013 11:29:08 -0700
>> From: Mike Swingler <swingler at apple.com>
>> Subject: Re: InstallAnywhere problems after Java for OS X 2013-004
>> 	Update
>> To: Stephen Coy <steve.coy at me.com>
>> Cc: "Braren, Arfst PT-RD23" <Arfst.Braren at heidelberg.com>,
>> 	"macosx-port-dev at openjdk.java.net" <macosx-port-dev at openjdk.java.net>
>> Message-ID: <ADCDB86B-FFCC-4E9C-9458-5EBC92E3F221 at apple.com>
>> Content-Type: text/plain; charset=windows-1252
>> 
>> We believe that we have addressed the issue:
>> <http://lists.apple.com/archives/java-dev/2013/Jun/msg00055.html>
>> 
>> Regards,
>> Mike Swingler
>> Apple Inc.
>> 
>> On Jun 20, 2013, at 5:52 AM, Stephen Coy <steve.coy at me.com> wrote:
>> 
>>> This Java release from Apple is generating a lot of dis-satisfied noises over on java-dev at lists.apple.com.
>>> 
>>> You're not alone?
>>> 
>>> On 19/06/2013, at 11:14 PM, "Braren, Arfst PT-RD23" <Arfst.Braren at heidelberg.com> wrote:
>>> 
>>>> We have trouble with our InstallerApps based on InstallAnywhere after the latest Updates.
>>>> 
>>>> 
>>>> Java for OS X 2013-004 seems to be the "troublemaker".
>>>> 
>>>> 
>>>> Any hints?
>>>> 
>>>> 
>>>> Kind regards
>>>> 
>>>> Arfst Braren
>> 
>> 
>> 
>> ------------------------------
>> 
>> _______________________________________________
>> macosx-port-dev mailing list
>> macosx-port-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/macosx-port-dev
>> 
>> 
>> End of macosx-port-dev Digest, Vol 30, Issue 9
>> **********************************************
> 


From james.b.tomson at gmail.com  Fri Jun 21 14:28:32 2013
From: james.b.tomson at gmail.com (James Tomson)
Date: Fri, 21 Jun 2013 17:28:32 -0400
Subject: AppContext issue in Apple Java 6 -- same issue in Oracle Java 7?
Message-ID: <CADGc6pgwqGr1ybhc1PzxU1hTb83gDyAK8ZHZVO_GbKE7FAHOZA@mail.gmail.com>

Hello,

We've been experiencing lockup issues with our Java Web Start application
on MacOSX since the introduction of 7u25. Running with 7u25, our
application is now invoking swing methods on both the AWT-EventQueue owned
by our 'main' thread group, as well as a queue instance owned by a
"javawsApplicationThreadGroup" group.

Now in this situation of dispatching events multiple AWT-EventQueues there
is a risk of deadlock, and in our case we've seen these fairly frequently
with 7u25, which renders our app unresponsive and must be forced quit.

Hopefully this deadlock issue is related to the fix for 6u51 involving
event dispatching with different AppContexts (since it seems a new
AppContext has been introduced in the javawsApplicationThreadGroup?) and
can be applied to 7 as well...

Cheers,
James

>Hi,
>Thanks for the links. I've skimmed through them and it looks like most of
them are about Apple Java. There are one or two links where people are
reporting 7u25 causing troubles, however, there is not enough evidence >to
conclude that it is the same problem as with Apple Java.
>
>On Jun 21, 2013, at 11:15 PM, Steve Kann <stevek at stevek.com> wrote:
>
>>
>> Mike and Mac Java folks,
>>
>> First -- Mike -- thank you and Apple for so quickly fixing the Java 6
update!
>>
>> We've been experiencing similar issues with Java 7 -- specifically with
webstart apps, but it seems that many others are seeing the same thing:
>>
>> (here's my little list of links, some to Java 6, some to Java 7, with
fallout):
>> http://scn.sap.com/message/14139064
>>
>> http://knowledgebase.pearsonschool.com/kmp/article/AA-07056
>>
>>
http://www.mathworks.us/matlabcentral/answers/79489-java-1-6-0_51-breaks-matlab-2012b-and-below
>>
http://www.geneious.com/web/geneious/news/-/blogs/java-update-for-geneious-mac
>>
>>
http://www.vassalengine.org/forum/viewtopic.php?f=3&t=6399&sid=4ff99c4e849a62b2ae745a0ad9d5afb6&start=15
>>
>>
http://blog.traderdealer.com.au/2013/06/21/latest-java-update-fix/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+onlinestockmarkettradingupdate+(Trader+Dealer+Blog)
>>
>>
http://www.extensis.com/support/knowledge-base/java-update-1-6-0_51-causes-startup-problems-with-uts-and-portfolio-server-on-mac-os-10-6-and-10-7/
>>
>>
>> Does anyone know:
>>
>> - If this problem is also the problem which has been hosing Java 7u25?
>> - If OpenJDK will be picking up a fix?
>> - If Oracle will be releasing a fix?
>>
>> Especially since on 10.7/10.8 Apple is now requiring 7u25 or later, it's
hard to ask users to rollback to 7u21.
>>
>> Thanks.
>>
>> -SteveK
>>
>>
>>
>>> Message: 1
>>> Date: Fri, 21 Jun 2013 11:29:08 -0700
>>> From: Mike Swingler <swingler at apple.com>
>>> Subject: Re: InstallAnywhere problems after Java for OS X 2013-004
>>> Update
>>> To: Stephen Coy <steve.coy at me.com>
>>> Cc: "Braren, Arfst PT-RD23" <Arfst.Braren at heidelberg.com>,
>>> "macosx-port-dev at openjdk.java.net" <macosx-port-dev at
openjdk.java.net>
>>> Message-ID: <ADCDB86B-FFCC-4E9C-9458-5EBC92E3F221 at apple.com>
>>> Content-Type: text/plain; charset=windows-1252
>>>
>>> We believe that we have addressed the issue:
>>> <http://lists.apple.com/archives/java-dev/2013/Jun/msg00055.html>
>>>
>>> Regards,
>>> Mike Swingler
>>> Apple Inc.
>>>
>>> On Jun 20, 2013, at 5:52 AM, Stephen Coy <steve.coy at me.com> wrote:
>>>
>>>> This Java release from Apple is generating a lot of dis-satisfied
noises over on java-dev at lists.apple.com.
>>>>
>>>> You're not alone?
>>>>
>>>> On 19/06/2013, at 11:14 PM, "Braren, Arfst PT-RD23" <Arfst.Braren at
heidelberg.com> wrote:
>>>>
>>>>> We have trouble with our InstallerApps based on InstallAnywhere after
the latest Updates.
>>>>>
>>>>>
>>>>> Java for OS X 2013-004 seems to be the "troublemaker".
>>>>>
>>>>>
>>>>> Any hints?
>>>>>
>>>>>
>>>>> Kind regards
>>>>>
>>>>> Arfst Braren
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> macosx-port-dev mailing list
>>> macosx-port-dev at openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/macosx-port-dev
>>>
>>>
>>> End of macosx-port-dev Digest, Vol 30, Issue 9
>>> **********************************************
>>

From mik3hall at gmail.com  Fri Jun 21 14:59:03 2013
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 21 Jun 2013 16:59:03 -0500
Subject: JNI and java threading
Message-ID: <82A7FD32-449D-499B-AECA-19F59B89745D@gmail.com>

I am going to more or less cross-post this since there may be people on different lists with more experience in the domains concerned, OS X, etc.
I have posted a question to the openjdk nio-dev list but aren't seeing any suggestions yet.

I have JNI that implements a kqueue Java 7 nio.2 WatchService. Part of my trz package below.
I am having trouble getting that to run the nio.2 stress test  LotsOfEvents.
(jdk/test/java/nio/file/WatchService/LotsOfEvents.java)

Basically, the test, at this point, creates 4096 files in a temp directory and then sleeps a while to try to build up a backlog.
Then it invokes a timed poll method against the events.
The first time this finds maybe 25-45 of the create events that have been called back from the native to java.
Then the test tries to timer re-poll for 2 seconds to see if it gets more.
For some reason the native thread posts no new events in that time period and the test fails.
Almost right after the test fails the native code resumes posting event callbacks until the error caused test shutdown completes. 

Is there some reason the java thread(s) are blocking the native thread? Has anyone run into similar.

What the native does?
	// Start new thread that fetches and processes our events:
	keepThreadRunning = YES;
	[NSThread detachNewThreadSelector:@selector(watcherThread:) toTarget:self withObject:nil];

It appears to be at the kevent invocation during the 'blocked' period.
    struct timespec     timeout = { 5, 0 }; // 5 seconds timeout.
			n = kevent64( queueFD, NULL, 0, &ev, 1, 0, &timeout );

This is the one time I've done anything with kqueue so maybe there is something I'm not understanding right there. Is there some reason I'm not aware of that it would go into an extended wait? With this invocation it normally seems to have about 12 events/sec throughput. Why would it go 3 seconds+ with 0 unless java is somehow blocking or priority pre-empting it? Is there some way I can be sure to get it to fire in time to keep the java 2 second poll alive?

Roughly what the java does for completeness?.
       WatchKey key = watcher.poll(15, TimeUnit.SECONDS);
        while (key != null) {
            List<WatchEvent<?>> events = key.pollEvents();
            for (WatchEvent<?> event: events) {
  
            }
            key = watcher.poll(2, TimeUnit.SECONDS);
        }

Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter





From leonid.romanov at oracle.com  Fri Jun 21 15:25:20 2013
From: leonid.romanov at oracle.com (Leonid Romanov)
Date: Sat, 22 Jun 2013 02:25:20 +0400
Subject: AppContext issue in Apple Java 6 -- same issue in Oracle Java 7?
In-Reply-To: <CADGc6pgwqGr1ybhc1PzxU1hTb83gDyAK8ZHZVO_GbKE7FAHOZA@mail.gmail.com>
References: <CADGc6pgwqGr1ybhc1PzxU1hTb83gDyAK8ZHZVO_GbKE7FAHOZA@mail.gmail.com>
Message-ID: <E302BCE5-06C9-4493-ABED-1B4ADBD4617F@oracle.com>

Hi,
Thanks for your report. Is your app available for download by the general public? There are things I'd like to check?

On Jun 22, 2013, at 1:28 AM, James Tomson <james.b.tomson at gmail.com> wrote:

> Hello,
> 
> We've been experiencing lockup issues with our Java Web Start application
> on MacOSX since the introduction of 7u25. Running with 7u25, our
> application is now invoking swing methods on both the AWT-EventQueue owned
> by our 'main' thread group, as well as a queue instance owned by a
> "javawsApplicationThreadGroup" group.
> 
> Now in this situation of dispatching events multiple AWT-EventQueues there
> is a risk of deadlock, and in our case we've seen these fairly frequently
> with 7u25, which renders our app unresponsive and must be forced quit.
> 
> Hopefully this deadlock issue is related to the fix for 6u51 involving
> event dispatching with different AppContexts (since it seems a new
> AppContext has been introduced in the javawsApplicationThreadGroup?) and
> can be applied to 7 as well...
> 
> Cheers,
> James
> 
>> Hi,
>> Thanks for the links. I've skimmed through them and it looks like most of
> them are about Apple Java. There are one or two links where people are
> reporting 7u25 causing troubles, however, there is not enough evidence >to
> conclude that it is the same problem as with Apple Java.
>> 
>> On Jun 21, 2013, at 11:15 PM, Steve Kann <stevek at stevek.com> wrote:
>> 
>>> 
>>> Mike and Mac Java folks,
>>> 
>>> First -- Mike -- thank you and Apple for so quickly fixing the Java 6
> update!
>>> 
>>> We've been experiencing similar issues with Java 7 -- specifically with
> webstart apps, but it seems that many others are seeing the same thing:
>>> 
>>> (here's my little list of links, some to Java 6, some to Java 7, with
> fallout):
>>> http://scn.sap.com/message/14139064
>>> 
>>> http://knowledgebase.pearsonschool.com/kmp/article/AA-07056
>>> 
>>> 
> http://www.mathworks.us/matlabcentral/answers/79489-java-1-6-0_51-breaks-matlab-2012b-and-below
>>> 
> http://www.geneious.com/web/geneious/news/-/blogs/java-update-for-geneious-mac
>>> 
>>> 
> http://www.vassalengine.org/forum/viewtopic.php?f=3&t=6399&sid=4ff99c4e849a62b2ae745a0ad9d5afb6&start=15
>>> 
>>> 
> http://blog.traderdealer.com.au/2013/06/21/latest-java-update-fix/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+onlinestockmarkettradingupdate+(Trader+Dealer+Blog)
>>> 
>>> 
> http://www.extensis.com/support/knowledge-base/java-update-1-6-0_51-causes-startup-problems-with-uts-and-portfolio-server-on-mac-os-10-6-and-10-7/
>>> 
>>> 
>>> Does anyone know:
>>> 
>>> - If this problem is also the problem which has been hosing Java 7u25?
>>> - If OpenJDK will be picking up a fix?
>>> - If Oracle will be releasing a fix?
>>> 
>>> Especially since on 10.7/10.8 Apple is now requiring 7u25 or later, it's
> hard to ask users to rollback to 7u21.
>>> 
>>> Thanks.
>>> 
>>> -SteveK
>>> 
>>> 
>>> 
>>>> Message: 1
>>>> Date: Fri, 21 Jun 2013 11:29:08 -0700
>>>> From: Mike Swingler <swingler at apple.com>
>>>> Subject: Re: InstallAnywhere problems after Java for OS X 2013-004
>>>> Update
>>>> To: Stephen Coy <steve.coy at me.com>
>>>> Cc: "Braren, Arfst PT-RD23" <Arfst.Braren at heidelberg.com>,
>>>> "macosx-port-dev at openjdk.java.net" <macosx-port-dev at
> openjdk.java.net>
>>>> Message-ID: <ADCDB86B-FFCC-4E9C-9458-5EBC92E3F221 at apple.com>
>>>> Content-Type: text/plain; charset=windows-1252
>>>> 
>>>> We believe that we have addressed the issue:
>>>> <http://lists.apple.com/archives/java-dev/2013/Jun/msg00055.html>
>>>> 
>>>> Regards,
>>>> Mike Swingler
>>>> Apple Inc.
>>>> 
>>>> On Jun 20, 2013, at 5:52 AM, Stephen Coy <steve.coy at me.com> wrote:
>>>> 
>>>>> This Java release from Apple is generating a lot of dis-satisfied
> noises over on java-dev at lists.apple.com.
>>>>> 
>>>>> You're not alone?
>>>>> 
>>>>> On 19/06/2013, at 11:14 PM, "Braren, Arfst PT-RD23" <Arfst.Braren at
> heidelberg.com> wrote:
>>>>> 
>>>>>> We have trouble with our InstallerApps based on InstallAnywhere after
> the latest Updates.
>>>>>> 
>>>>>> 
>>>>>> Java for OS X 2013-004 seems to be the "troublemaker".
>>>>>> 
>>>>>> 
>>>>>> Any hints?
>>>>>> 
>>>>>> 
>>>>>> Kind regards
>>>>>> 
>>>>>> Arfst Braren
>>>> 
>>>> 
>>>> 
>>>> ------------------------------
>>>> 
>>>> _______________________________________________
>>>> macosx-port-dev mailing list
>>>> macosx-port-dev at openjdk.java.net
>>>> http://mail.openjdk.java.net/mailman/listinfo/macosx-port-dev
>>>> 
>>>> 
>>>> End of macosx-port-dev Digest, Vol 30, Issue 9
>>>> **********************************************
>>> 


From jfinley at tech4learning.com  Mon Jun 24 11:09:49 2013
From: jfinley at tech4learning.com (Jessica Finley)
Date: Mon, 24 Jun 2013 12:09:49 -0600
Subject: VolatileImages render incorrectly
Message-ID: <D98BC83F-6D5E-4175-AB18-7CA8D3ED09BF@tech4learning.com>

Hiya folks,

I've run into a couple of problems with OpenJDK on Mac.  Firstly, and what started me down this path, is the performance of rendering BufferedImages seems to have really tanked.  It's as if they are not supported by hardware anymore (from vague references I've seen around the web, I understand that BufferedImages are supposed to be hardware accelerated.. and based on the performance on Windows (java 7) and Mac Java 6, I can believe that).  In OpenJDK 7 and 8, rendering lots of BufferedImages causes performance to truly and horribly suffer on certain Macs (the Macs with the low end graphics cards really seem to show this, but it's noticeable on all Macs I've tested on).

In an effort to speed up our software, I started using VolatileImages instead of BufferedImages in certain places and it has brought performance up to awesome.  However, I noticed the problem that I describe in Sun Bug Id: 9004409.  When I paint VolatileImage.getSnapshot() to either the screen graphics or to a BufferedImage, the transparent pixels are rendered incorrectly - they have black values instead of transparent values, as if the transparent pixels were first rendered over a solid black background and then the result is what is copied out to the BufferedImage.

Now, if I render the VolatileImage directly to the screen graphics, I don't see the problem, but any way I can figure out how to render the VolatileImage to or as a BufferedImage results in incorrect transparent pixels.

Below is a sample program that demonstrates the problem and compares it to BufferedImages which always render correctly.  

This problem only occurs on Mac Java 7 and 8? all works as expected on Windows Java 7 and Mac Java 6.

Any thoughts on this?  Is there a work around anyone knows of?  Also, am I correct in my conjecture that BufferedImages are supposed to be hardware accelerated, but they are not in OpenJDK?

Thanks for your time,
Jess

----------------------------------------

import java.awt.AlphaComposite;
import java.awt.BorderLayout;
import java.awt.Color;
import java.awt.Dimension;
import java.awt.Graphics2D;
import java.awt.GraphicsConfiguration;
import java.awt.GraphicsEnvironment;
import java.awt.GridBagConstraints;
import java.awt.GridBagLayout;
import java.awt.Insets;
import java.awt.Transparency;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.awt.image.BufferedImage;
import java.awt.image.VolatileImage;

import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.JPanel;
import javax.swing.SwingUtilities;

/**
 * Shows the difference between the painting of a translucent BufferedImage and a translucent
 * VolatileImage.
 * 
 * 
 * On Java 6, this works fine.  On Java 7, the VolatileImages are not painted correctly, when painted
 * onto a BufferedImage prior to being painted to screen graphics.
 * 
 * @author jfinley
 *
 */
public class PaintTest {

	public PaintTest() {
		
		JPanel bufferedImagePanel = new JPanel() {
			protected void paintComponent(java.awt.Graphics g) {
				super.paintComponent(g);
				BufferedImage image = getBufferedImage();
				g.drawImage(image, 0, 0, null);
			};
		};

		JPanel bufferedImagePanel2 = new JPanel() {
			protected void paintComponent(java.awt.Graphics g) {
				super.paintComponent(g);
				BufferedImage bImage = getBufferedImage();
				
				BufferedImage image = new BufferedImage(100, 100, BufferedImage.TYPE_INT_ARGB);
				Graphics2D g2 = image.createGraphics();
				
				//not really necessary, but in there for completeness
				g2.setComposite(AlphaComposite.Clear);
				g2.setColor(new Color(255, 255, 255, 0));
				g2.fillRect(0,0, image.getWidth(), image.getHeight());
				
				g2.setComposite(AlphaComposite.SrcOver);
				g2.drawImage(bImage,  0, 0, null);
				g2.dispose();
				
				g.drawImage(image, 0, 0, null);
			};
		};
		
		JPanel volatileImagePanel = new JPanel() {
			protected void paintComponent(java.awt.Graphics g) {
				super.paintComponent(g);
				VolatileImage vImage = getVolatileImage();
				
				/**
				 * If we draw the VolatileImage directly to g, it works fine... but
				 * if we draw VolatileImage.getSnapshot(), or otherwise convert the VolatileImage
				 * to a buffered image, we get the black halo funk of death.
				 */
				g.drawImage(vImage, 0, 0, null); //works
				//g.drawImage(vImage.getSnapshot(), 0, 0, null); //black halo funk of death
			};
		};
		
		JPanel volatileImagePanel2 = new JPanel() {
			protected void paintComponent(java.awt.Graphics g) {
				super.paintComponent(g);
				VolatileImage vImage = getVolatileImage();
				
				/**
				 * If we draw the VolatileImage directly to g, it works fine... but
				 * if we draw VolatileImage.getSnapshot(), or otherwise convert the VolatileImage
				 * to a buffered image, we get the black halo funk of death.
				 */
				//g.drawImage(vImage, 0, 0, null); //works
				g.drawImage(vImage.getSnapshot(), 0, 0, null); //black halo funk of death
			};
		};
		
		JPanel volatileImagePanel3 = new JPanel() {
			protected void paintComponent(java.awt.Graphics g) {
				super.paintComponent(g);
				VolatileImage vImage = getVolatileImage();
				
				/**
				 * If we draw the VolatileImage directly to g, it works fine... but
				 * if we draw VolatileImage.getSnapshot(), or otherwise convert the VolatileImage
				 * to a buffered image, we get the black halo funk of death.
				 */
				//g.drawImage(vImage, 0, 0, null); //works
				//g.drawImage(vImage.getSnapshot(), 0, 0, null); //black halo funk of death
				
				BufferedImage image = new BufferedImage(100, 100, BufferedImage.TYPE_INT_ARGB);
				Graphics2D g2 = image.createGraphics();
				
				//not really necessary, but in there for completeness
				g2.setComposite(AlphaComposite.Clear);
				g2.setColor(new Color(255, 255, 255, 0));
				g2.fillRect(0,0, image.getWidth(), image.getHeight());
				
				g2.setComposite(AlphaComposite.SrcOver);
				g2.drawImage(vImage,  0, 0, null);
				g2.dispose();
				
				g.drawImage(image, 0, 0, null);
			};
		};

		final JPanel mainPanel = new JPanel(new GridBagLayout());
		GridBagConstraints gbc = new GridBagConstraints(0, 1, 1, 1, 0, 0, 
				GridBagConstraints.CENTER, GridBagConstraints.BOTH, new Insets(0, 0, 0, 0), 0, 0);

		mainPanel.add(new JLabel("Direct to g"), gbc);
		gbc.gridy++;
		mainPanel.add(new JLabel("BufferImage Proxy"), gbc);
		gbc.gridy++;
		mainPanel.add(new JLabel("BufferImage Proxy 2"), gbc);
		
		gbc.gridx = 1; gbc.gridy = 0;
		mainPanel.add(new JLabel("BufferedImages"), gbc);
		gbc.gridx++;
		mainPanel.add(new JLabel("VolatileImages"), gbc);

		gbc.gridx = 1; gbc.gridy = 1; gbc.weightx = 1; gbc.weighty = 1;
		mainPanel.add(bufferedImagePanel, gbc);
		gbc.gridy++;
		mainPanel.add(bufferedImagePanel2, gbc);
		gbc.gridx = 2; gbc.gridy = 1;
		mainPanel.add(volatileImagePanel, gbc);
		gbc.gridy++;
		mainPanel.add(volatileImagePanel2, gbc);
		gbc.gridy++;
		mainPanel.add(volatileImagePanel3, gbc);

		
		JButton repaintButton = new JButton("Repaint");
		repaintButton.addActionListener(new ActionListener(){
			public void actionPerformed(ActionEvent e) {
				mainPanel.repaint();
			}
		});
		
		gbc.gridx = 1; gbc.gridy++; gbc.gridwidth = 2; gbc.weighty = 0;
		mainPanel.add(repaintButton, gbc);


		JFrame mainFrame = new JFrame("O.M.G.");
		mainFrame.getContentPane().setLayout(new BorderLayout());
		mainFrame.getContentPane().add(mainPanel, BorderLayout.CENTER);
		mainFrame.setPreferredSize(new Dimension(400, 400));
		mainFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
		mainFrame.pack();
		mainFrame.setVisible(true);
		
	}
	
	private BufferedImage getBufferedImage() {
		BufferedImage image = new BufferedImage(100, 100, BufferedImage.TRANSLUCENT);
		Graphics2D g = image.createGraphics();
		
		//not really necessary, in here for completeness
		g.setComposite(AlphaComposite.Clear);
		g.setColor(new Color(255, 255, 255, 0));
		g.fillRect(0,0, image.getWidth(), image.getHeight());
		
		g.setComposite(AlphaComposite.SrcOver);
		g.setColor(new Color(255, 0, 0, 128));
		g.fillRect(10, 10, image.getWidth()-20, image.getHeight()-20);

		g.dispose();
		return image;
	}

	private VolatileImage getVolatileImage() {
		GraphicsConfiguration gc = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration();
		VolatileImage vImage = gc.createCompatibleVolatileImage(100, 100, Transparency.TRANSLUCENT);
		Graphics2D g = vImage.createGraphics();
		
		//necessary, as VolatileImages start out filled opaque white
		g.setComposite(AlphaComposite.Clear);
		g.setColor(new Color(255, 255, 255, 0));
		g.fillRect(0,0, vImage.getWidth(), vImage.getHeight());
		
		g.setComposite(AlphaComposite.SrcOver);
		g.setColor(new Color(255, 0, 0, 128));
		g.fillRect(10, 10, vImage.getWidth()-20, vImage.getHeight()-20);

		g.dispose();
		return vImage;
	}

	public static void main(String[] args) {
		SwingUtilities.invokeLater(new Runnable(){
			public void run() {
				new PaintTest();
			}
		});
	}
}

From weijun.wang at oracle.com  Mon Jun 24 22:39:52 2013
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 25 Jun 2013 13:39:52 +0800
Subject: Mac awt regression? (was JDK-8017189: [macosx]Step9: After openning
	the "File" menu, the items are disabled; regression since b94)
In-Reply-To: <97306224-9950-43EC-BC71-5CD12F4BC23A@oracle.com>
References: <784026037.5157.1371743884451.JavaMail.jbsadmin@aojmv0001.oracle.com>
	<51C393C8.6070702@oracle.com> <51C3A241.1040300@oracle.com>
	<51C3A2A1.6050109@oracle.com>
	<97306224-9950-43EC-BC71-5CD12F4BC23A@oracle.com>
Message-ID: <51C92D28.1030306@oracle.com>

Hi All

Sorry to write in HTML. I need to add a table.

The bug is about after several clicks on policytool a menu item is
disabled. I've simplified the tool to a small program (attached) with
the same behavior. Running the program in JDK 7 and 8 on Mac shows these
differences:


	JDK 7
	JDK 8
Start the app 	New in File menu is enabled
	New in File menu is enabled (same as JDK 7)
Click button one, dialog one pops up
	File menu disappears
	New in File menu is disabled
Click button two, dialog two pops up
	
	File menu disappears
Close dialog two
	
	No change
Close dialog one
	File menu reappear with New enabled
	File menu reappears, but New still disabled
Command+Q to quite the app
	
	


Is this a regression?

Thanks
Max
-------------- next part --------------
import java.awt.*;
import java.awt.event.*;

public class A2 {

    public static void main(String args[]) {
        ToolWindow tw = new ToolWindow();
        tw.displayToolWindow();
    }
}

class ToolWindow extends Frame {
    void displayToolWindow() {

        setBounds(135, 80, 500, 500);

        MenuBar menuBar = new MenuBar();
        Menu menu = new Menu("File");
        menu.add("New");
        menuBar.add(menu);
        setMenuBar(menuBar);

        Button button = new Button("One");
        button.addActionListener(new MainWindowListener(this));
        this.add(button);

        setVisible(true);
    }
}

class ToolDialog extends Dialog {
    ToolWindow tw;

    ToolDialog(String title, ToolWindow tw) {
        super(tw, true);
        setTitle(title);
        this.tw = tw;
        addWindowListener(new ChildWindowListener(this));
    }

    void displayPolicyEntryDialog(boolean edit) {

        Point location = tw.getLocationOnScreen();
        setBounds(location.x + 75, location.y + 200, 650, 500);

        Button button = new Button("Add Two");
        button.addActionListener(new AddPrinButtonListener(this));
        this.add(button);
        setVisible(true);
    }

    void displayPrincipalDialog() {
        ToolDialog newTD = new ToolDialog("Two", tw);
        Point location = getLocationOnScreen();
        newTD.setBounds(location.x + 50, location.y + 100, 650, 190);
        newTD.setVisible(true);
    }
}

class MainWindowListener implements ActionListener {

    private ToolWindow tw;

    MainWindowListener(ToolWindow tw) {
        this.tw = tw;
    }

    public void actionPerformed(ActionEvent e) {
        ToolDialog td = new ToolDialog("One", tw);
        td.displayPolicyEntryDialog(false);
    }
}

class AddPrinButtonListener implements ActionListener {

    private ToolDialog td;

    AddPrinButtonListener(ToolDialog td) {
        this.td = td;
    }

    public void actionPerformed(ActionEvent e) {
        td.displayPrincipalDialog();
    }
}

class ChildWindowListener implements WindowListener {
    private ToolDialog td;

    ChildWindowListener(ToolDialog td) {
        this.td = td;
    }

    public void windowClosing(WindowEvent we) {
        td.setVisible(false);
        td.dispose();
    }

    public void windowOpened(WindowEvent we) { }
    public void windowClosed(WindowEvent we) {}
    public void windowIconified(WindowEvent we) {}
    public void windowDeiconified(WindowEvent we) {}
    public void windowActivated(WindowEvent we) {}
    public void windowDeactivated(WindowEvent we) {}
}

From ca at censhare.de  Wed Jun 26 03:42:21 2013
From: ca at censhare.de (Christof Aenderl)
Date: Wed, 26 Jun 2013 12:42:21 +0200
Subject: LWWindowPeer dispatchMouseEvent removed in 7_25
Message-ID: <C85C7F2F-E099-443A-B9A5-8DF1BFD02097@censhare.de>

Hi,

the dispatchMouseEvent method was removed from LWWindowPeer with Update 25 of Java 7.

Why was it removed?
I had implemented a workaround to handle mouse-moved events from JNI which not worked with 7_21 or less
that uses this method.

Kind regards,
Christof

From anthony.petrov at oracle.com  Wed Jun 26 04:09:33 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Wed, 26 Jun 2013 15:09:33 +0400
Subject: LWWindowPeer dispatchMouseEvent removed in 7_25
In-Reply-To: <C85C7F2F-E099-443A-B9A5-8DF1BFD02097@censhare.de>
References: <C85C7F2F-E099-443A-B9A5-8DF1BFD02097@censhare.de>
Message-ID: <51CACBED.2000209@oracle.com>

Hi Christof,

LWWindowPeer is not a part of public API. Its internal implementation 
may change at any moment. Your code shouldn't rely on any implementation 
details.

Can you rework you application to use public APIs only?

--
best regards,
Anthony

On 06/26/2013 02:42 PM, Christof Aenderl wrote:
> Hi,
>
> the dispatchMouseEvent method was removed from LWWindowPeer with Update 25 of Java 7.
>
> Why was it removed?
> I had implemented a workaround to handle mouse-moved events from JNI which not worked with 7_21 or less
> that uses this method.
>
> Kind regards,
> Christof
>

From petr.pchelko at oracle.com  Wed Jun 26 04:09:53 2013
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 26 Jun 2013 15:09:53 +0400
Subject: LWWindowPeer dispatchMouseEvent removed in 7_25
In-Reply-To: <C85C7F2F-E099-443A-B9A5-8DF1BFD02097@censhare.de>
References: <C85C7F2F-E099-443A-B9A5-8DF1BFD02097@censhare.de>
Message-ID: <52F10415-FDD8-4E10-9AF7-2FC257086A9C@oracle.com>

Hello, Cristof.

Looks like the method is still there. It was renamed to notifyMouseEvent.

And what is the bug you we making a workaround for?

With best regards. Petr.

On Jun 26, 2013, at 2:42 PM, Christof Aenderl wrote:

> Hi,
> 
> the dispatchMouseEvent method was removed from LWWindowPeer with Update 25 of Java 7.
> 
> Why was it removed?
> I had implemented a workaround to handle mouse-moved events from JNI which not worked with 7_21 or less
> that uses this method.
> 
> Kind regards,
> Christof


From ca at censhare.de  Wed Jun 26 06:09:11 2013
From: ca at censhare.de (Christof Aenderl)
Date: Wed, 26 Jun 2013 15:09:11 +0200
Subject: LWWindowPeer dispatchMouseEvent removed in 7_25
In-Reply-To: <52F10415-FDD8-4E10-9AF7-2FC257086A9C@oracle.com>
References: <C85C7F2F-E099-443A-B9A5-8DF1BFD02097@censhare.de>
	<52F10415-FDD8-4E10-9AF7-2FC257086A9C@oracle.com>
Message-ID: <6878F734-BFE9-4DAD-8F85-074C0EC574BD@censhare.de>

Hi Petr,

as Anthony mentioned, I should try to rework that code using public API.

What actually my issue was, is to create a global floating utility window which takes more afford using sun.lwawt.macosx than apple.awt from Java 6 (CEmbeddedFrame).
For that I had to implement a method to handle mouse events from the native class (AWTContentView).

Best regards,
Christof

Am 26.06.2013 um 13:09 schrieb Petr Pchelko <petr.pchelko at oracle.com>:

> Hello, Cristof.
> 
> Looks like the method is still there. It was renamed to notifyMouseEvent.
> 
> And what is the bug you we making a workaround for?
> 
> With best regards. Petr.
> 
> On Jun 26, 2013, at 2:42 PM, Christof Aenderl wrote:
> 
>> Hi,
>> 
>> the dispatchMouseEvent method was removed from LWWindowPeer with Update 25 of Java 7.
>> 
>> Why was it removed?
>> I had implemented a workaround to handle mouse-moved events from JNI which not worked with 7_21 or less
>> that uses this method.
>> 
>> Kind regards,
>> Christof



From Doug.Zwick at blackboard.com  Wed Jun 26 15:46:39 2013
From: Doug.Zwick at blackboard.com (Doug Zwick)
Date: Wed, 26 Jun 2013 18:46:39 -0400
Subject: AppContext issue in Apple Java 6 -- same issue in Oracle Java 7?
In-Reply-To: <mailman.1.1371927601.20815.macosx-port-dev@openjdk.java.net>
References: <mailman.1.1371927601.20815.macosx-port-dev@openjdk.java.net>
Message-ID: <E8BEEA48-D12E-43D5-BE06-DFCBC6677998@blackboard.com>

James Tomson wrote:

> We've been experiencing lockup issues with our Java Web Start application
> on MacOSX since the introduction of 7u25. Running with 7u25, our
> application is now invoking swing methods on both the AWT-EventQueue owned
> by our 'main' thread group, as well as a queue instance owned by a
> "javawsApplicationThreadGroup" group.
>
> Now in this situation of dispatching events multiple AWT-EventQueues there
> is a risk of deadlock, and in our case we've seen these fairly frequently
> with 7u25, which renders our app unresponsive and must be forced quit.

I have dug deeper into this, and we are somehow getting our code running on AWT-EventQueue-0 in the "main" ThreadGroup, and not on AWT-EventQueue-2 in the "javawsApplicationThreadGroup" group. One way this will happen is callbacks on the AppKit thread, as we can see in the thread dumps that AWT-AppKit is in the "main" group. However, it is not just our JNI code that can cause this, it looks like the EAWT API for wiring up the About, Preferences and Quit menu items in the application menu will queue their callbacks up on AWT-EventQueue-0 as well, as per this stack trace I generated by instrumenting requests to our Swing invokeLater bottleneck routine:

  @ com.elluminate.platform.macos.MacAppUtils$CocoaEventProxy.handleAbout(MacAppUtils.java:197)
  @ com.apple.eawt._AppEventLegacyHandler$1.dispatchEvent(_AppEventLegacyHandler.java:97)
  @ com.apple.eawt._AppEventLegacyHandler.sendEventToEachListenerUntilHandled(_AppEventLegacyHandler.java:188)
  @ com.apple.eawt._AppEventLegacyHandler.handleAbout(_AppEventLegacyHandler.java:95)
  @ com.apple.eawt._AppEventHandler$_AboutDispatcher.performUsing(_AppEventHandler.java:248)
  @ com.apple.eawt._AppEventHandler$_AboutDispatcher.performUsing(_AppEventHandler.java:242)
  @ com.apple.eawt._AppEventHandler$_AppEventDispatcher$1.run(_AppEventHandler.java:497)
  @ java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251)
  @ java.awt.EventQueue.dispatchEventImpl(EventQueue.java:733)
  @ java.awt.EventQueue.access$200(EventQueue.java:103)
  @ java.awt.EventQueue$3.run(EventQueue.java:694)
  @ java.awt.EventQueue$3.run(EventQueue.java:692)
  @ java.security.AccessController.doPrivileged(Native Method)
  @ java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
  @ java.awt.EventQueue.dispatchEvent(EventQueue.java:703)
  @ java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
  @ java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
  @ java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
  @ java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
  @ java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
  @ java.awt.EventDispatchThread.run(EventDispatchThread.java:91)

This call was made on AWT-EventQueue-0, in the "main" ThreadGroup. It looks like the EAWT code needs to be updated to shift into the proper thread group before trying to queue its "_AppEventDispatcher$1" anonymous Runnable on the EDT.

The "Legacy" in "AppEventLegacyHandler" is interesting. I'll have to dig deeper, and verify that we are using the current API for registering the About/Preferences/Quit handlers.

This email and any attachments may contain confidential and proprietary information of Blackboard that is for the sole use of the intended recipient. If you are not the intended recipient, disclosure, copying, re-distribution or other use of any of this information is strictly prohibited. Please immediately notify the sender and delete this transmission if you received this email in error.

From mik3hall at gmail.com  Wed Jun 26 17:55:26 2013
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 26 Jun 2013 19:55:26 -0500
Subject: AppContext issue in Apple Java 6 -- same issue in Oracle Java 7?
In-Reply-To: <E8BEEA48-D12E-43D5-BE06-DFCBC6677998@blackboard.com>
References: <mailman.1.1371927601.20815.macosx-port-dev@openjdk.java.net>
	<E8BEEA48-D12E-43D5-BE06-DFCBC6677998@blackboard.com>
Message-ID: <48FF7D86-1A7C-4C99-BA97-B765CB02AE0C@gmail.com>

On Jun 26, 2013, at 5:46 PM, Doug Zwick wrote:

> I have dug deeper into this, and we are somehow getting our code running on AWT-EventQueue-0 in the "main" ThreadGroup, and not on AWT-EventQueue-2 in the "javawsApplicationThreadGroup" group

This is normal for applications, if not jws, maybe jws is running more like platform app's now?
From my HalfPipe app.

dojava
javax.swing.SwingUtilities.invokeLater(new Runnable() { public void run() { System.out.println(Thread.currentThread() + " " + javax.swing.SwingUtilities.isEventDispatchThread()); }});
Thread[AWT-EventQueue-0,6,main] true
dojava: done

Although I was sort of remembering the AppKit thread being the actual EDT? Must be a misremember there.
You aren't showing a deadlock. I think actual instances of stack crawls showing deadlock would be more useful to go on if theres a problem.
As I remember there have been multiple AWT-EventQueue-# threads going back a long time, these haven't been a deadlock problem previously that I remember.
Thread group I'm not sure how would apply?

Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter






From Doug.Zwick at blackboard.com  Thu Jun 27 09:25:41 2013
From: Doug.Zwick at blackboard.com (Doug Zwick)
Date: Thu, 27 Jun 2013 12:25:41 -0400
Subject: AppContext issue in Apple Java 6 -- same issue in Oracle Java 7?
In-Reply-To: <48FF7D86-1A7C-4C99-BA97-B765CB02AE0C@gmail.com>
References: <mailman.1.1371927601.20815.macosx-port-dev@openjdk.java.net>
	<E8BEEA48-D12E-43D5-BE06-DFCBC6677998@blackboard.com>
	<48FF7D86-1A7C-4C99-BA97-B765CB02AE0C@gmail.com>
Message-ID: <E53C2A00-7BDE-4FFC-A4DF-96DCAAB318B5@blackboard.com>


On 2013-06-26, at 6:55 PM, Michael Hall wrote:

> On Jun 26, 2013, at 5:46 PM, Doug Zwick wrote:
>
>> I have dug deeper into this, and we are somehow getting our code running on AWT-EventQueue-0 in the "main" ThreadGroup, and not on AWT-EventQueue-2 in the "javawsApplicationThreadGroup" group
>
> This is normal for applications, if not jws, maybe jws is running more like platform app's now?
> From my HalfPipe app.
>
> dojava
> javax.swing.SwingUtilities.invokeLater(new Runnable() { public void run() { System.out.println(Thread.currentThread() + " " + javax.swing.SwingUtilities.isEventDispatchThread()); }});
> Thread[AWT-EventQueue-0,6,main] true
> dojava: done
>
> Although I was sort of remembering the AppKit thread being the actual EDT? Must be a misremember there.
> You aren't showing a deadlock. I think actual instances of stack crawls showing deadlock would be more useful to go on if theres a problem.
> As I remember there have been multiple AWT-EventQueue-# threads going back a long time, these haven't been a deadlock problem previously that I remember.
> Thread group I'm not sure how would apply?

Stand-alone apps typically have only one Swing event thread, AWT-EventQueue-0. When running under Web Start, apps typically have had two (-0 and -1), up through Java 7u21. These seem to be bound to the two different AppContext instances present in JWS apps. I didn't look into which one was the "right" EDT for the web start app code in 7u21.

Starting in 7u25, there are now three EDTs, -0, -1 and -2 that correspond to three different AppContexts. The threads of the process seem to be grouped in the same manner, with a thread group for each AppContext. As a heuristic, we can look at the ThreadGroup of the calling thread, and from that deduce which AppContext it is running in. AWT-EventQueue-0 seems bound to the "main" ThreadGroup (at least in our app), -1 seems bound to the "javawsSecurityThreadGroup" ThreadGroup, and -2 seems bound to the "javawsApplicationThreadGroup" ThreadGroup. There is also a "system" ThreadGroup, but that one has now AWT-EventQueue-x thread in it. The "javawsApplicationThreadGroup" group is where all our application threads are grouped (which is also new behaviour in 7u25, in 7u21 we had some threads running in "main"). "AppKit Thread" is a member of the "main" ThreadGroup. It looks like all native code callbacks on the AppKit thread will send any Runnables queued with SwingUtilities.invokeLater to AWT-EventQueue-0, and not AWT-EventQueue-2. This causes problems. The most obvious one is deadlocks. We were often getting situations where both AWT-EventQueue-0 and AWT-EventQueue-2 were contesting the AWT Tree Lock. Since different code paths through Swing acquire locks in different orders relative to acquiring the Tree Lock, we readily wound up in a state where one EDT held the Tree Lock and was waiting for another lock, while the other EDT had that other lock and was waiting for the Tree Lock. The only way that can happen is if an event has been posted to the wrong EDT. If the different EDTs routinely contested the same AWT Tree Lock, JWS apps would always be deadlocking. The different AppContexts must provide independent Swing/AWT environments to ensure that this does not happen.

However, the problem with menu items is worse than I first thought. In addition to the About, Preferences and Quit menu items calling back through the EAWT interface on the wrong thread, it turns out that EVERY menu item in the screen menu bar responds to mouse activation by posting the ActionListener.actionPerformed event to the wrong EDT, namely the EDT associated with the "main" thread group, and not the EDT associated with our application code. It is interesting to note that activation via accelerator key causes the event to be posted to the correct EDT.

We are working around this by checking the ThreadGroup before queuing Runnables with SwingUtilities.invokeLater, and if the ThreadGroup of the calling thread is not the same ThreadGroup associated with our main application startup thread (which we cache at startup time), we instead queue the Runnable for a worker thread that is running in the correct ThreadGroup and AppContext, and have it then queue the Runnable onto the EDT. This works well for invokeLater, but is more of a pain for invokeAndWait calls. Our deadlocks seem to have disappeared.

We appear to have a related issue with Apple's 1.6.0_51 build, where we cannot open windows in callbacks from screen menu bar menu items (or they open but their content does not paint). This does not appear to be an issue under 7u25.


This email and any attachments may contain confidential and proprietary information of Blackboard that is for the sole use of the intended recipient. If you are not the intended recipient, disclosure, copying, re-distribution or other use of any of this information is strictly prohibited. Please immediately notify the sender and delete this transmission if you received this email in error.

From Doug.Zwick at blackboard.com  Thu Jun 27 09:40:43 2013
From: Doug.Zwick at blackboard.com (Doug Zwick)
Date: Thu, 27 Jun 2013 12:40:43 -0400
Subject: AppContext issue in Apple Java 6 -- same issue in Oracle Java 7?
In-Reply-To: <48FF7D86-1A7C-4C99-BA97-B765CB02AE0C@gmail.com>
References: <mailman.1.1371927601.20815.macosx-port-dev@openjdk.java.net>
	<E8BEEA48-D12E-43D5-BE06-DFCBC6677998@blackboard.com>
	<48FF7D86-1A7C-4C99-BA97-B765CB02AE0C@gmail.com>
Message-ID: <F7875F01-4D6A-479A-A02E-2159814715AB@blackboard.com>

Here is an example of the deadlocks we were seeing:

"AWT-EventQueue-0" prio=5 tid=0x00007fd234895000 nid=0x9a03 waiting for monitor entry [0x00000001381a9000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at java.awt.Component.invalidate(Component.java:2916)
        - waiting to lock <0x0000000110335ae8> (a java.awt.Component$AWTTreeLock)
        at java.awt.Container.invalidate(Container.java:1580)
        at javax.swing.JComponent.revalidate(JComponent.java:4851)
        at javax.swing.plaf.basic.BasicTextUI$RootView.preferenceChanged(BasicTextUI.java:1406)
        at javax.swing.text.View.preferenceChanged(View.java:289)
        at javax.swing.text.PlainView.updateDamage(PlainView.java:566)
        at javax.swing.text.PlainView.insertUpdate(PlainView.java:451)
        at javax.swing.text.FieldView.insertUpdate(FieldView.java:293)
        at javax.swing.plaf.basic.BasicTextUI$RootView.insertUpdate(BasicTextUI.java:1602)
        at javax.swing.plaf.basic.BasicTextUI$UpdateHandler.insertUpdate(BasicTextUI.java:1861)
        at javax.swing.text.AbstractDocument.fireInsertUpdate(AbstractDocument.java:202)
        at javax.swing.text.AbstractDocument.handleInsertString(AbstractDocument.java:749)
        at javax.swing.text.AbstractDocument.insertString(AbstractDocument.java:708)
        at javax.swing.text.PlainDocument.insertString(PlainDocument.java:130)
        at javax.swing.text.AbstractDocument.replace(AbstractDocument.java:670)
        at javax.swing.text.JTextComponent.setText(JTextComponent.java:1718)
?

"AWT-EventQueue-1" prio=5 tid=0x00007fd23489d000 nid=0x9d03 waiting for monitor entry [0x00000001384b2000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at java.awt.Container.getMouseEventTargetImpl(Container.java:2390)
    - waiting to lock <0x0000000110335ae8> (a java.awt.Component$AWTTreeLock)
    at java.awt.Container.getMouseEventTarget(Container.java:2356)
    at java.awt.Container.getMouseEventTarget(Container.java:2319)
    at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4470)
    at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4422)
    at java.awt.Container.dispatchEventImpl(Container.java:2273)
    at java.awt.Window.dispatchEventImpl(Window.java:2719)
    at java.awt.Component.dispatchEvent(Component.java:4687)
?

"AWT-EventQueue-2" prio=5 tid=0x00007fd233823000 nid=0x9517 in Object.wait() [0x000000013e023000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x000000012d9c1458> (a javax.swing.text.PlainDocument)
    at java.lang.Object.wait(Object.java:503)
    at javax.swing.text.AbstractDocument.readLock(AbstractDocument.java:1387)
    - locked <0x000000012d9c1458> (a javax.swing.text.PlainDocument)
    at javax.swing.plaf.basic.BasicTextUI.paint(BasicTextUI.java:878)
    at javax.swing.plaf.basic.BasicTextUI.update(BasicTextUI.java:860)
    at javax.swing.JComponent.paintComponent(JComponent.java:778)
    at javax.swing.JComponent.paint(JComponent.java:1054)
    at javax.swing.JComponent.paintChildren(JComponent.java:887)
    - locked <0x0000000110335ae8> (a java.awt.Component$AWTTreeLock)
    at javax.swing.JComponent.paint(JComponent.java:1063)
    at javax.swing.JComponent.paintToOffscreen(JComponent.java:5221)
    at javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(RepaintManager.java:1508)
    at javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1439)

I'm not sure why AWT-EventQueue-1 seems to be contesting the same AWTTreeLock instance as -0 and -2. AFAIK, we were not getting caught up with the AWT-EventQueue-1 AppContext.

And here is an example of a stack trace from AWT-EventQueue-0 when dispatching an ActionListener.actionPerformed event triggered by the mouse on a screen menu bar menu item:

    at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2018)
    at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2341)
    at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
    at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
    at javax.swing.AbstractButton.doClick(AbstractButton.java:376)
    at com.apple.laf.ScreenMenuItem.actionPerformed(ScreenMenuItem.java:128)
    at java.awt.MenuItem.processActionEvent(MenuItem.java:669)
    at java.awt.MenuItem.processEvent(MenuItem.java:628)
    at java.awt.MenuComponent.dispatchEventImpl(MenuComponent.java:351)
    at java.awt.MenuComponent.dispatchEvent(MenuComponent.java:339)
    at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:738)
    at java.awt.EventQueue.access$200(EventQueue.java:103)
    at java.awt.EventQueue$3.run(EventQueue.java:694)
    at java.awt.EventQueue$3.run(EventQueue.java:692)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
    at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:87)
    at java.awt.EventQueue$4.run(EventQueue.java:708)
    at java.awt.EventQueue$4.run(EventQueue.java:706)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
    at java.awt.EventQueue.dispatchEvent(EventQueue.java:705)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
    at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
    at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)

The next frame in that stack trace is our ActionListener.actionPerformed implementation. No deadlocks involved, just calling us back from the wrong EDT.


This email and any attachments may contain confidential and proprietary information of Blackboard that is for the sole use of the intended recipient. If you are not the intended recipient, disclosure, copying, re-distribution or other use of any of this information is strictly prohibited. Please immediately notify the sender and delete this transmission if you received this email in error.

From mik3hall at gmail.com  Thu Jun 27 15:34:26 2013
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 27 Jun 2013 17:34:26 -0500
Subject: AppContext issue in Apple Java 6 -- same issue in Oracle Java 7?
In-Reply-To: <E53C2A00-7BDE-4FFC-A4DF-96DCAAB318B5@blackboard.com>
References: <mailman.1.1371927601.20815.macosx-port-dev@openjdk.java.net>
	<E8BEEA48-D12E-43D5-BE06-DFCBC6677998@blackboard.com>
	<48FF7D86-1A7C-4C99-BA97-B765CB02AE0C@gmail.com>
	<E53C2A00-7BDE-4FFC-A4DF-96DCAAB318B5@blackboard.com>
Message-ID: <613768AB-CBC7-4BBE-8904-6565147FA198@gmail.com>

> Stand-alone apps typically have only one Swing event thread, AWT-EventQueue-0. 

True, I checked, my app does only have -0.

> Starting in 7u25, there are now three EDTs, -0, -1 and -2 that correspond to three different AppContexts. 

When I start JWS I only get -0, -1. Maybe AppContext gets you another. I'm on a 1.8 build which is probably not the best comparison.

> We are working around this by checking the ThreadGroup before queuing Runnables with SwingUtilities.invokeLater, and if the ThreadGroup of the calling thread is not the same ThreadGroup associated with our main application startup thread (which we cache at startup time),

Curious is this the same one as?
Toolkit.getDefaultToolkit().getSystemEventQueue()

as per here?
http://stackoverflow.com/questions/9873391/safe-way-to-replace-awt-eventqueue-in-running-swing-application

If consistently the right one that might be easier to use than the cached startup one.

I'm not sure theres anything else in the stack overflow you'd find useful. Although I might think that another workaround could be replace all dup EventQueue instances with ones that delegate to the one you actually want. Probably not of interest if you already have a workaround that is probably easier to implement than this.

Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter




On Jun 27, 2013, at 11:25 AM, Doug Zwick wrote:

> 
> On 2013-06-26, at 6:55 PM, Michael Hall wrote:
> 
>> On Jun 26, 2013, at 5:46 PM, Doug Zwick wrote:
>> 
>>> I have dug deeper into this, and we are somehow getting our code running on AWT-EventQueue-0 in the "main" ThreadGroup, and not on AWT-EventQueue-2 in the "javawsApplicationThreadGroup" group
>> 
>> This is normal for applications, if not jws, maybe jws is running more like platform app's now?
>> From my HalfPipe app.
>> 
>> dojava
>> javax.swing.SwingUtilities.invokeLater(new Runnable() { public void run() { System.out.println(Thread.currentThread() + " " + javax.swing.SwingUtilities.isEventDispatchThread()); }});
>> Thread[AWT-EventQueue-0,6,main] true
>> dojava: done
>> 
>> Although I was sort of remembering the AppKit thread being the actual EDT? Must be a misremember there.
>> You aren't showing a deadlock. I think actual instances of stack crawls showing deadlock would be more useful to go on if theres a problem.
>> As I remember there have been multiple AWT-EventQueue-# threads going back a long time, these haven't been a deadlock problem previously that I remember.
>> Thread group I'm not sure how would apply?
> 
> Stand-alone apps typically have only one Swing event thread, AWT-EventQueue-0. When running under Web Start, apps typically have had two (-0 and -1), up through Java 7u21. These seem to be bound to the two different AppContext instances present in JWS apps. I didn't look into which one was the "right" EDT for the web start app code in 7u21.
> 
> Starting in 7u25, there are now three EDTs, -0, -1 and -2 that correspond to three different AppContexts. The threads of the process seem to be grouped in the same manner, with a thread group for each AppContext. As a heuristic, we can look at the ThreadGroup of the calling thread, and from that deduce which AppContext it is running in. AWT-EventQueue-0 seems bound to the "main" ThreadGroup (at least in our app), -1 seems bound to the "javawsSecurityThreadGroup" ThreadGroup, and -2 seems bound to the "javawsApplicationThreadGroup" ThreadGroup. There is also a "system" ThreadGroup, but that one has now AWT-EventQueue-x thread in it. The "javawsApplicationThreadGroup" group is where all our application threads are grouped (which is also new behaviour in 7u25, in 7u21 we had some threads running in "main"). "AppKit Thread" is a member of the "main" ThreadGroup. It looks like all native code callbacks on the AppKit thread will send any Runnables queued with SwingUtilities.invokeLater to AWT-EventQueue-0, and not AWT-EventQueue-2. This causes problems. The most obvious one is deadlocks. We were often getting situations where both AWT-EventQueue-0 and AWT-EventQueue-2 were contesting the AWT Tree Lock. Since different code paths through Swing acquire locks in different orders relative to acquiring the Tree Lock, we readily wound up in a state where one EDT held the Tree Lock and was waiting for another lock, while the other EDT had that other lock and was waiting for the Tree Lock. The only way that can happen is if an event has been posted to the wrong EDT. If the different EDTs routinely contested the same AWT Tree Lock, JWS apps would always be deadlocking. The different AppContexts must provide independent Swing/AWT environments to ensure that this does not happen.
> 
> However, the problem with menu items is worse than I first thought. In addition to the About, Preferences and Quit menu items calling back through the EAWT interface on the wrong thread, it turns out that EVERY menu item in the screen menu bar responds to mouse activation by posting the ActionListener.actionPerformed event to the wrong EDT, namely the EDT associated with the "main" thread group, and not the EDT associated with our application code. It is interesting to note that activation via accelerator key causes the event to be posted to the correct EDT.
> 
>  we instead queue the Runnable for a worker thread that is running in the correct ThreadGroup and AppContext, and have it then queue the Runnable onto the EDT. This works well for invokeLater, but is more of a pain for invokeAndWait calls. Our deadlocks seem to have disappeared.
> 
> We appear to have a related issue with Apple's 1.6.0_51 build, where we cannot open windows in callbacks from screen menu bar menu items (or they open but their content does not paint). This does not appear to be an issue under 7u25.
> 
> 
> This email and any attachments may contain confidential and proprietary information of Blackboard that is for the sole use of the intended recipient. If you are not the intended recipient, disclosure, copying, re-distribution or other use of any of this information is strictly prohibited. Please immediately notify the sender and delete this transmission if you received this email in error.


From Doug.Zwick at blackboard.com  Thu Jun 27 15:47:40 2013
From: Doug.Zwick at blackboard.com (Doug Zwick)
Date: Thu, 27 Jun 2013 18:47:40 -0400
Subject: AppContext issue in Apple Java 6 -- same issue in Oracle Java 7?
In-Reply-To: <613768AB-CBC7-4BBE-8904-6565147FA198@gmail.com>
References: <mailman.1.1371927601.20815.macosx-port-dev@openjdk.java.net>
	<E8BEEA48-D12E-43D5-BE06-DFCBC6677998@blackboard.com>
	<48FF7D86-1A7C-4C99-BA97-B765CB02AE0C@gmail.com>
	<E53C2A00-7BDE-4FFC-A4DF-96DCAAB318B5@blackboard.com>
	<613768AB-CBC7-4BBE-8904-6565147FA198@gmail.com>
Message-ID: <285F3639-5D93-4D21-81F5-F1DC2C03C8D3@blackboard.com>

Michael Hall wrote:

>> We are working around this by checking the ThreadGroup before queuing Runnables with SwingUtilities.invokeLater, and if the ThreadGroup of the calling thread is not the same ThreadGroup associated with our main application startup thread (which we cache at startup time),
>
> Curious is this the same one as?
> Toolkit.getDefaultToolkit().getSystemEventQueue()
>
> as per here?
> http://stackoverflow.com/questions/9873391/safe-way-to-replace-awt-eventqueue-in-running-swing-application
>
> If consistently the right one that might be easier to use than the cached startup one.

That might also eliminate the need to go through a worker thread just to get to the right event queue. Thanks for the link.

> I'm not sure theres anything else in the stack overflow you'd find useful. Although I might think that another workaround could be replace all dup EventQueue instances with ones that delegate to the one you actually want. Probably not of interest if you already have a workaround that is probably easier to implement than this.

I'd be worried about derailing anything in the other AppContexts that might depend on the operation of these other event queues, for example the console window.


This email and any attachments may contain confidential and proprietary information of Blackboard that is for the sole use of the intended recipient. If you are not the intended recipient, disclosure, copying, re-distribution or other use of any of this information is strictly prohibited. Please immediately notify the sender and delete this transmission if you received this email in error.

From mik3hall at gmail.com  Thu Jun 27 16:27:33 2013
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 27 Jun 2013 18:27:33 -0500
Subject: AppContext issue in Apple Java 6 -- same issue in Oracle Java 7?
In-Reply-To: <285F3639-5D93-4D21-81F5-F1DC2C03C8D3@blackboard.com>
References: <mailman.1.1371927601.20815.macosx-port-dev@openjdk.java.net>
	<E8BEEA48-D12E-43D5-BE06-DFCBC6677998@blackboard.com>
	<48FF7D86-1A7C-4C99-BA97-B765CB02AE0C@gmail.com>
	<E53C2A00-7BDE-4FFC-A4DF-96DCAAB318B5@blackboard.com>
	<613768AB-CBC7-4BBE-8904-6565147FA198@gmail.com>
	<285F3639-5D93-4D21-81F5-F1DC2C03C8D3@blackboard.com>
Message-ID: <E4FC4DDD-499E-479D-B64D-F4327D797977@gmail.com>

On Jun 27, 2013, at 5:47 PM, Doug Zwick wrote:

> I'd be worried about derailing anything in the other AppContexts that might depend on the operation of these other event queues, for example the console window.

My first thought had been eliminate the duplicates but there might be some derailing there too, if code expects it's thread group for some reason to have an EventQueue that it's going to try and use no matter what. If the code is smart enough to realize the thread is dead before trying to dispatch to it and then search and find another this might work.

Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter






From Erik.Vanherck at inventivegroup.com  Fri Jun 28 05:57:35 2013
From: Erik.Vanherck at inventivegroup.com (Erik Vanherck)
Date: Fri, 28 Jun 2013 12:57:35 +0000
Subject: AppContext issues breaks -XstartOnFirstThread for multithreaded
	programs on both 6_51 and 7_25
Message-ID: <6D01C8B3-4990-4761-976C-532F5288EE8C@inventivegroup.com>

Hi,

I wanted to weigh in a bit since although many people are complaining about the AWT/Swing and webstart issues, it goes much further than that. The AppContext can trigger AWT loading from many locations even as simple as java.util.logging or jmx. In my mind I find it extremely suspicious that these low level utility classes should try to do anything with AWT, especially considering server apps.

This test program results in a hang in the spawned thread trying to load in one of the 3 places both on Apple java 1.6.0_51 (with and without the Apple 09 hotfix) and Java 1.7.0_25. It runs as normal java applications, no applet or webstart required, no security manager set, Just add -XstartOnFirstThread to the commandline.

import java.lang.management.ManagementFactory;
import java.util.logging.Logger;

import javax.imageio.spi.IIORegistry;
import javax.management.MBeanServer;

/**
 * @author evanherc
 */
public class AppContextJVMBug {

public static void main(String[] args) {
try {
System.out.println("Launching");

final Thread t = new Thread(new Runnable() {
public void run() {
try {
utilLoggingHang();
jmxHang();
imageioHang();
} catch (Throwable t) {
t.printStackTrace();
}
}
});

t.start();
t.join();
System.out.println("Finished");
} catch (Throwable t) {
t.printStackTrace();
}
}

private static void utilLoggingHang() {
final Logger l = Logger.getLogger("MyApp");
System.out.println("Done obtaining a logger " + l);
}

private static void jmxHang() {
final MBeanServer mb = ManagementFactory.getPlatformMBeanServer();
System.out.println("Done getting the platform mbean server " + mb);
}

private static void imageioHang() {
final IIORegistry registry = IIORegistry.getDefaultInstance();
System.out.println("Done retrieving image registry " + registry);
}
}



Tested on several Apple Mac OS X 10.8.4 machines.
Without JVM arguments : runs fine
With -XstartOnFirstThread : hangs
With -XstartOnFirstThread and -Djava.awt.headless=true : runs fine

Here's actual stack traces from our large product suites. They break for everyone as we run inside Eclipse and as such have to specify -XstartOnFirstThread.
I've seen a dozen variants now (there is other classes triggering AppContext as well).

"Thread-4" daemon prio=5 tid=7febb49ae800 nid=0x10f2fb000 runnable [10f2f6000]
   java.lang.Thread.State: RUNNABLE
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1827)
- locked <7dc02aec0> (a java.util.Vector)
- locked <7dc02aee0> (a java.util.Vector)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1724)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
- locked <7dc02cb28> (a java.lang.Runtime)
at java.lang.System.loadLibrary(System.java:1045)
at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:50)
at java.security.AccessController.doPrivileged(Native Method)
at java.awt.Toolkit.loadLibraries(Toolkit.java:1605)
at java.awt.Toolkit.<clinit>(Toolkit.java:1627)
at sun.awt.AppContext$2.run(AppContext.java:240)
at sun.awt.AppContext$2.run(AppContext.java:226)
at java.security.AccessController.doPrivileged(Native Method)
at sun.awt.AppContext.initMainAppContext(AppContext.java:226)
at sun.awt.AppContext.access$200(AppContext.java:112)
at sun.awt.AppContext$3.run(AppContext.java:306)
at java.security.AccessController.doPrivileged(Native Method)
at sun.awt.AppContext.getAppContext(AppContext.java:287)
at com.sun.jmx.trace.Trace.out(Trace.java:180)
- locked <7f8eea490> (a java.lang.Class for com.sun.jmx.trace.Trace)
at com.sun.jmx.trace.Trace.isSelected(Trace.java:88)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.isTraceOn(DefaultMBeanServerInterceptor.java:1830)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:929)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:916)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312)
at com.sun.jmx.mbeanserver.JmxMBeanServer$2.run(JmxMBeanServer.java:1195)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.jmx.mbeanserver.JmxMBeanServer.initialize(JmxMBeanServer.java:1193)
at com.sun.jmx.mbeanserver.JmxMBeanServer.<init>(JmxMBeanServer.java:225)
at com.sun.jmx.mbeanserver.JmxMBeanServer.<init>(JmxMBeanServer.java:170)
at com.sun.jmx.mbeanserver.JmxMBeanServer.newMBeanServer(JmxMBeanServer.java:1401)
at javax.management.MBeanServerBuilder.newMBeanServer(MBeanServerBuilder.java:93)
at javax.management.MBeanServerFactory.newMBeanServer(MBeanServerFactory.java:311)
- locked <7d824f618> (a javax.management.MBeanServerBuilder)
at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:214)
at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:175)
at sun.management.ManagementFactory.createPlatformMBeanServer(ManagementFactory.java:302)
at java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:504)
- locked <7f8e00140> (a java.lang.Class for java.lang.management.ManagementFactory)
at id.core.version.provider.ProductVersionProvider.<init>(ProductVersionProvider.java:68)
at id.core.version.provider.ProductVersionProvider.getInstance(ProductVersionProvider.java:37)
- locked <7f8dd00a8> (a java.lang.Class for id.core.version.provider.ProductVersionProvider)
at id.core.version.VersionInfo.getProductID(VersionInfo.java:98)
at com.id.core.platform.util.application.ProductDirectories.calculateCurrentUserProgramDir(ProductDirectories.java:31)
at com.id.core.platform.util.application.ProductDirectories.<clinit>(ProductDirectories.java:22)
at com.id.core.platform.repository.BundleRepository.parsePluginFile(BundleRepository.java:235)
at com.id.core.platform.repository.BundleRepository.<init>(BundleRepository.java:101)
at com.id.core.platform.Platform.bootstrap(Platform.java:178)
- locked <7d81cb4c8> (a java.lang.Object)
- locked <7d81cb4a8> (a com.id.core.platform.Platform)
at com.id.core.platform.activator.Activator$1.run(Activator.java:77)
- locked <7d81aca68> (a java.lang.Object)

"Thread-2" prio=5 tid=0x00007f9973093800 nid=0x7e03 runnable [0x0000000137b2f000]
   java.lang.Thread.State: RUNNABLE
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1957)
- locked <0x0000000128bc39a8> (a java.util.Vector)
- locked <0x0000000128bc3610> (a java.util.Vector)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1882)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1843)
at java.lang.Runtime.load0(Runtime.java:795)
- locked <0x0000000110a457a8> (a java.lang.Runtime)
at java.lang.System.load(System.java:1061)
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1957)
- locked <0x0000000128bc39a8> (a java.util.Vector)
- locked <0x0000000128bc3610> (a java.util.Vector)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1882)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1864)
at java.lang.Runtime.loadLibrary0(Runtime.java:849)
- locked <0x0000000110a457a8> (a java.lang.Runtime)
at java.lang.System.loadLibrary(System.java:1087)
at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:67)
at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:47)
at java.security.AccessController.doPrivileged(Native Method)
at java.awt.Toolkit.loadLibraries(Toolkit.java:1646)
at java.awt.Toolkit.<clinit>(Toolkit.java:1668)
at sun.awt.AppContext$2.run(AppContext.java:271)
at sun.awt.AppContext$2.run(AppContext.java:260)
at java.security.AccessController.doPrivileged(Native Method)
at sun.awt.AppContext.initMainAppContext(AppContext.java:260)
at sun.awt.AppContext.access$200(AppContext.java:133)
at sun.awt.AppContext$3.run(AppContext.java:316)
at sun.awt.AppContext$3.run(AppContext.java:298)
at java.security.AccessController.doPrivileged(Native Method)
at sun.awt.AppContext.getAppContext(AppContext.java:297)
at javax.imageio.spi.IIORegistry.getDefaultInstance(IIORegistry.java:154)
at com.id.external.javax.media.jai.Services.register(Services.java:20)
at com.id.external.javax.media.jai.activator.Activator.start(Activator.java:26)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711)
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683)
at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:299)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:291)
at com.id.core.platform.repository.BundleRepository.startBundle(BundleRepository.java:486)
at com.id.core.platform.repository.BundleRepository.handleResolvedBundle(BundleRepository.java:389)
at com.id.core.platform.repository.BundleRepository.scanBundles(BundleRepository.java:269)
at com.id.core.platform.repository.BundleRepository.start(BundleRepository.java:118)
- locked <0x00000001259d7d20> (a java.lang.Object)
at com.id.core.platform.Platform.bootstrap(Platform.java:184)
- locked <0x00000001259d4000> (a java.lang.Object)
- locked <0x00000001259d3fe0> (a com.id.core.platform.Platform)
at com.id.core.platform.activator.Activator$1.run(Activator.java:77)
- locked <0x00000001259ce758> (a java.lang.Object)

I've been looking in the source but not sure if those fixes are already in the jdk 1.7u forest.

Erik Vanherck

________________________________

Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer

From anthony.petrov at oracle.com  Fri Jun 28 07:06:33 2013
From: anthony.petrov at oracle.com (Anthony Petrov)
Date: Fri, 28 Jun 2013 18:06:33 +0400
Subject: AppContext issues breaks -XstartOnFirstThread for multithreaded
	programs on both 6_51 and 7_25
In-Reply-To: <6D01C8B3-4990-4761-976C-532F5288EE8C@inventivegroup.com>
References: <6D01C8B3-4990-4761-976C-532F5288EE8C@inventivegroup.com>
Message-ID: <51CD9869.5000004@oracle.com>

Hi Erik,

While this does look like a bug (please file it at http://bugs.sun.com), 
I have a question. Since this is not a GUI app, why would you run it 
with -XstartOnFirstThread ? What exactly are you trying to achieve with 
this command-line switch?

--
best regards,
Anthony

On 06/28/2013 04:57 PM, Erik Vanherck wrote:
> Hi,
>
> I wanted to weigh in a bit since although many people are complaining about the AWT/Swing and webstart issues, it goes much further than that. The AppContext can trigger AWT loading from many locations even as simple as java.util.logging or jmx. In my mind I find it extremely suspicious that these low level utility classes should try to do anything with AWT, especially considering server apps.
>
> This test program results in a hang in the spawned thread trying to load in one of the 3 places both on Apple java 1.6.0_51 (with and without the Apple 09 hotfix) and Java 1.7.0_25. It runs as normal java applications, no applet or webstart required, no security manager set, Just add -XstartOnFirstThread to the commandline.
>
> import java.lang.management.ManagementFactory;
> import java.util.logging.Logger;
>
> import javax.imageio.spi.IIORegistry;
> import javax.management.MBeanServer;
>
> /**
>   * @author evanherc
>   */
> public class AppContextJVMBug {
>
> public static void main(String[] args) {
> try {
> System.out.println("Launching");
>
> final Thread t = new Thread(new Runnable() {
> public void run() {
> try {
> utilLoggingHang();
> jmxHang();
> imageioHang();
> } catch (Throwable t) {
> t.printStackTrace();
> }
> }
> });
>
> t.start();
> t.join();
> System.out.println("Finished");
> } catch (Throwable t) {
> t.printStackTrace();
> }
> }
>
> private static void utilLoggingHang() {
> final Logger l = Logger.getLogger("MyApp");
> System.out.println("Done obtaining a logger " + l);
> }
>
> private static void jmxHang() {
> final MBeanServer mb = ManagementFactory.getPlatformMBeanServer();
> System.out.println("Done getting the platform mbean server " + mb);
> }
>
> private static void imageioHang() {
> final IIORegistry registry = IIORegistry.getDefaultInstance();
> System.out.println("Done retrieving image registry " + registry);
> }
> }
>
>
>
> Tested on several Apple Mac OS X 10.8.4 machines.
> Without JVM arguments : runs fine
> With -XstartOnFirstThread : hangs
> With -XstartOnFirstThread and -Djava.awt.headless=true : runs fine
>
> Here's actual stack traces from our large product suites. They break for everyone as we run inside Eclipse and as such have to specify -XstartOnFirstThread.
> I've seen a dozen variants now (there is other classes triggering AppContext as well).
>
> "Thread-4" daemon prio=5 tid=7febb49ae800 nid=0x10f2fb000 runnable [10f2f6000]
>     java.lang.Thread.State: RUNNABLE
> at java.lang.ClassLoader$NativeLibrary.load(Native Method)
> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1827)
> - locked <7dc02aec0> (a java.util.Vector)
> - locked <7dc02aee0> (a java.util.Vector)
> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1724)
> at java.lang.Runtime.loadLibrary0(Runtime.java:823)
> - locked <7dc02cb28> (a java.lang.Runtime)
> at java.lang.System.loadLibrary(System.java:1045)
> at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:50)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.awt.Toolkit.loadLibraries(Toolkit.java:1605)
> at java.awt.Toolkit.<clinit>(Toolkit.java:1627)
> at sun.awt.AppContext$2.run(AppContext.java:240)
> at sun.awt.AppContext$2.run(AppContext.java:226)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.awt.AppContext.initMainAppContext(AppContext.java:226)
> at sun.awt.AppContext.access$200(AppContext.java:112)
> at sun.awt.AppContext$3.run(AppContext.java:306)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.awt.AppContext.getAppContext(AppContext.java:287)
> at com.sun.jmx.trace.Trace.out(Trace.java:180)
> - locked <7f8eea490> (a java.lang.Class for com.sun.jmx.trace.Trace)
> at com.sun.jmx.trace.Trace.isSelected(Trace.java:88)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.isTraceOn(DefaultMBeanServerInterceptor.java:1830)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:929)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:916)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312)
> at com.sun.jmx.mbeanserver.JmxMBeanServer$2.run(JmxMBeanServer.java:1195)
> at java.security.AccessController.doPrivileged(Native Method)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.initialize(JmxMBeanServer.java:1193)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.<init>(JmxMBeanServer.java:225)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.<init>(JmxMBeanServer.java:170)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.newMBeanServer(JmxMBeanServer.java:1401)
> at javax.management.MBeanServerBuilder.newMBeanServer(MBeanServerBuilder.java:93)
> at javax.management.MBeanServerFactory.newMBeanServer(MBeanServerFactory.java:311)
> - locked <7d824f618> (a javax.management.MBeanServerBuilder)
> at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:214)
> at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:175)
> at sun.management.ManagementFactory.createPlatformMBeanServer(ManagementFactory.java:302)
> at java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:504)
> - locked <7f8e00140> (a java.lang.Class for java.lang.management.ManagementFactory)
> at id.core.version.provider.ProductVersionProvider.<init>(ProductVersionProvider.java:68)
> at id.core.version.provider.ProductVersionProvider.getInstance(ProductVersionProvider.java:37)
> - locked <7f8dd00a8> (a java.lang.Class for id.core.version.provider.ProductVersionProvider)
> at id.core.version.VersionInfo.getProductID(VersionInfo.java:98)
> at com.id.core.platform.util.application.ProductDirectories.calculateCurrentUserProgramDir(ProductDirectories.java:31)
> at com.id.core.platform.util.application.ProductDirectories.<clinit>(ProductDirectories.java:22)
> at com.id.core.platform.repository.BundleRepository.parsePluginFile(BundleRepository.java:235)
> at com.id.core.platform.repository.BundleRepository.<init>(BundleRepository.java:101)
> at com.id.core.platform.Platform.bootstrap(Platform.java:178)
> - locked <7d81cb4c8> (a java.lang.Object)
> - locked <7d81cb4a8> (a com.id.core.platform.Platform)
> at com.id.core.platform.activator.Activator$1.run(Activator.java:77)
> - locked <7d81aca68> (a java.lang.Object)
>
> "Thread-2" prio=5 tid=0x00007f9973093800 nid=0x7e03 runnable [0x0000000137b2f000]
>     java.lang.Thread.State: RUNNABLE
> at java.lang.ClassLoader$NativeLibrary.load(Native Method)
> at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1957)
> - locked <0x0000000128bc39a8> (a java.util.Vector)
> - locked <0x0000000128bc3610> (a java.util.Vector)
> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1882)
> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1843)
> at java.lang.Runtime.load0(Runtime.java:795)
> - locked <0x0000000110a457a8> (a java.lang.Runtime)
> at java.lang.System.load(System.java:1061)
> at java.lang.ClassLoader$NativeLibrary.load(Native Method)
> at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1957)
> - locked <0x0000000128bc39a8> (a java.util.Vector)
> - locked <0x0000000128bc3610> (a java.util.Vector)
> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1882)
> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1864)
> at java.lang.Runtime.loadLibrary0(Runtime.java:849)
> - locked <0x0000000110a457a8> (a java.lang.Runtime)
> at java.lang.System.loadLibrary(System.java:1087)
> at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:67)
> at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:47)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.awt.Toolkit.loadLibraries(Toolkit.java:1646)
> at java.awt.Toolkit.<clinit>(Toolkit.java:1668)
> at sun.awt.AppContext$2.run(AppContext.java:271)
> at sun.awt.AppContext$2.run(AppContext.java:260)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.awt.AppContext.initMainAppContext(AppContext.java:260)
> at sun.awt.AppContext.access$200(AppContext.java:133)
> at sun.awt.AppContext$3.run(AppContext.java:316)
> at sun.awt.AppContext$3.run(AppContext.java:298)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.awt.AppContext.getAppContext(AppContext.java:297)
> at javax.imageio.spi.IIORegistry.getDefaultInstance(IIORegistry.java:154)
> at com.id.external.javax.media.jai.Services.register(Services.java:20)
> at com.id.external.javax.media.jai.activator.Activator.start(Activator.java:26)
> at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702)
> at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683)
> at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381)
> at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:299)
> at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:291)
> at com.id.core.platform.repository.BundleRepository.startBundle(BundleRepository.java:486)
> at com.id.core.platform.repository.BundleRepository.handleResolvedBundle(BundleRepository.java:389)
> at com.id.core.platform.repository.BundleRepository.scanBundles(BundleRepository.java:269)
> at com.id.core.platform.repository.BundleRepository.start(BundleRepository.java:118)
> - locked <0x00000001259d7d20> (a java.lang.Object)
> at com.id.core.platform.Platform.bootstrap(Platform.java:184)
> - locked <0x00000001259d4000> (a java.lang.Object)
> - locked <0x00000001259d3fe0> (a com.id.core.platform.Platform)
> at com.id.core.platform.activator.Activator$1.run(Activator.java:77)
> - locked <0x00000001259ce758> (a java.lang.Object)
>
> I've been looking in the source but not sure if those fixes are already in the jdk 1.7u forest.
>
> Erik Vanherck
>
> ________________________________
>
> Inventive Designers' Email Disclaimer:
> http://www.inventivedesigners.com/email-disclaimer
>

From Erik.Vanherck at inventivegroup.com  Fri Jun 28 08:27:08 2013
From: Erik.Vanherck at inventivegroup.com (Erik Vanherck)
Date: Fri, 28 Jun 2013 15:27:08 +0000
Subject: AppContext issues breaks -XstartOnFirstThread for multithreaded
	programs on both 6_51 and 7_25
In-Reply-To: <51CD9869.5000004@oracle.com>
References: <6D01C8B3-4990-4761-976C-532F5288EE8C@inventivegroup.com>,
	<51CD9869.5000004@oracle.com>
Message-ID: <E9B7F930-77EF-4573-98DF-668A8BC1949D@inventivegroup.com>

Nothing really, it was just the simplest test case i came up with. The issue for us is we use swt based apps and even installers all throughout our product suite which do require the parameter and all of them hang at startup. We have one product  which uses the swt_awt bridge as well so we are well aware of the mess there but this is preventing any of the apps to properly work.

As my test case shows even apps which don't go anywhere near awt (or so they think) will end up with hangs, so it won't be long I guess until some eclipse projects will start bumping into the same issue

Sent from my iPhone

On 28 Jun 2013, at 16:52, "Anthony Petrov" <anthony.petrov at oracle.com> wrote:

> Hi Erik,
>
> While this does look like a bug (please file it at http://bugs.sun.com), I have a question. Since this is not a GUI app, why would you run it with -XstartOnFirstThread ? What exactly are you trying to achieve with this command-line switch?
>
> --
> best regards,
> Anthony
>
> On 06/28/2013 04:57 PM, Erik Vanherck wrote:
>> Hi,
>>
>> I wanted to weigh in a bit since although many people are complaining about the AWT/Swing and webstart issues, it goes much further than that. The AppContext can trigger AWT loading from many locations even as simple as java.util.logging or jmx. In my mind I find it extremely suspicious that these low level utility classes should try to do anything with AWT, especially considering server apps.
>>
>> This test program results in a hang in the spawned thread trying to load in one of the 3 places both on Apple java 1.6.0_51 (with and without the Apple 09 hotfix) and Java 1.7.0_25. It runs as normal java applications, no applet or webstart required, no security manager set, Just add -XstartOnFirstThread to the commandline.
>>
>> import java.lang.management.ManagementFactory;
>> import java.util.logging.Logger;
>>
>> import javax.imageio.spi.IIORegistry;
>> import javax.management.MBeanServer;
>>
>> /**
>>  * @author evanherc
>>  */
>> public class AppContextJVMBug {
>>
>> public static void main(String[] args) {
>> try {
>> System.out.println("Launching");
>>
>> final Thread t = new Thread(new Runnable() {
>> public void run() {
>> try {
>> utilLoggingHang();
>> jmxHang();
>> imageioHang();
>> } catch (Throwable t) {
>> t.printStackTrace();
>> }
>> }
>> });
>>
>> t.start();
>> t.join();
>> System.out.println("Finished");
>> } catch (Throwable t) {
>> t.printStackTrace();
>> }
>> }
>>
>> private static void utilLoggingHang() {
>> final Logger l = Logger.getLogger("MyApp");
>> System.out.println("Done obtaining a logger " + l);
>> }
>>
>> private static void jmxHang() {
>> final MBeanServer mb = ManagementFactory.getPlatformMBeanServer();
>> System.out.println("Done getting the platform mbean server " + mb);
>> }
>>
>> private static void imageioHang() {
>> final IIORegistry registry = IIORegistry.getDefaultInstance();
>> System.out.println("Done retrieving image registry " + registry);
>> }
>> }
>>
>>
>>
>> Tested on several Apple Mac OS X 10.8.4 machines.
>> Without JVM arguments : runs fine
>> With -XstartOnFirstThread : hangs
>> With -XstartOnFirstThread and -Djava.awt.headless=true : runs fine
>>
>> Here's actual stack traces from our large product suites. They break for everyone as we run inside Eclipse and as such have to specify -XstartOnFirstThread.
>> I've seen a dozen variants now (there is other classes triggering AppContext as well).
>>
>> "Thread-4" daemon prio=5 tid=7febb49ae800 nid=0x10f2fb000 runnable [10f2f6000]
>>    java.lang.Thread.State: RUNNABLE
>> at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1827)
>> - locked <7dc02aec0> (a java.util.Vector)
>> - locked <7dc02aee0> (a java.util.Vector)
>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1724)
>> at java.lang.Runtime.loadLibrary0(Runtime.java:823)
>> - locked <7dc02cb28> (a java.lang.Runtime)
>> at java.lang.System.loadLibrary(System.java:1045)
>> at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:50)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at java.awt.Toolkit.loadLibraries(Toolkit.java:1605)
>> at java.awt.Toolkit.<clinit>(Toolkit.java:1627)
>> at sun.awt.AppContext$2.run(AppContext.java:240)
>> at sun.awt.AppContext$2.run(AppContext.java:226)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at sun.awt.AppContext.initMainAppContext(AppContext.java:226)
>> at sun.awt.AppContext.access$200(AppContext.java:112)
>> at sun.awt.AppContext$3.run(AppContext.java:306)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at sun.awt.AppContext.getAppContext(AppContext.java:287)
>> at com.sun.jmx.trace.Trace.out(Trace.java:180)
>> - locked <7f8eea490> (a java.lang.Class for com.sun.jmx.trace.Trace)
>> at com.sun.jmx.trace.Trace.isSelected(Trace.java:88)
>> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.isTraceOn(DefaultMBeanServerInterceptor.java:1830)
>> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:929)
>> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:916)
>> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312)
>> at com.sun.jmx.mbeanserver.JmxMBeanServer$2.run(JmxMBeanServer.java:1195)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at com.sun.jmx.mbeanserver.JmxMBeanServer.initialize(JmxMBeanServer.java:1193)
>> at com.sun.jmx.mbeanserver.JmxMBeanServer.<init>(JmxMBeanServer.java:225)
>> at com.sun.jmx.mbeanserver.JmxMBeanServer.<init>(JmxMBeanServer.java:170)
>> at com.sun.jmx.mbeanserver.JmxMBeanServer.newMBeanServer(JmxMBeanServer.java:1401)
>> at javax.management.MBeanServerBuilder.newMBeanServer(MBeanServerBuilder.java:93)
>> at javax.management.MBeanServerFactory.newMBeanServer(MBeanServerFactory.java:311)
>> - locked <7d824f618> (a javax.management.MBeanServerBuilder)
>> at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:214)
>> at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:175)
>> at sun.management.ManagementFactory.createPlatformMBeanServer(ManagementFactory.java:302)
>> at java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:504)
>> - locked <7f8e00140> (a java.lang.Class for java.lang.management.ManagementFactory)
>> at id.core.version.provider.ProductVersionProvider.<init>(ProductVersionProvider.java:68)
>> at id.core.version.provider.ProductVersionProvider.getInstance(ProductVersionProvider.java:37)
>> - locked <7f8dd00a8> (a java.lang.Class for id.core.version.provider.ProductVersionProvider)
>> at id.core.version.VersionInfo.getProductID(VersionInfo.java:98)
>> at com.id.core.platform.util.application.ProductDirectories.calculateCurrentUserProgramDir(ProductDirectories.java:31)
>> at com.id.core.platform.util.application.ProductDirectories.<clinit>(ProductDirectories.java:22)
>> at com.id.core.platform.repository.BundleRepository.parsePluginFile(BundleRepository.java:235)
>> at com.id.core.platform.repository.BundleRepository.<init>(BundleRepository.java:101)
>> at com.id.core.platform.Platform.bootstrap(Platform.java:178)
>> - locked <7d81cb4c8> (a java.lang.Object)
>> - locked <7d81cb4a8> (a com.id.core.platform.Platform)
>> at com.id.core.platform.activator.Activator$1.run(Activator.java:77)
>> - locked <7d81aca68> (a java.lang.Object)
>>
>> "Thread-2" prio=5 tid=0x00007f9973093800 nid=0x7e03 runnable [0x0000000137b2f000]
>>    java.lang.Thread.State: RUNNABLE
>> at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>> at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1957)
>> - locked <0x0000000128bc39a8> (a java.util.Vector)
>> - locked <0x0000000128bc3610> (a java.util.Vector)
>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1882)
>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1843)
>> at java.lang.Runtime.load0(Runtime.java:795)
>> - locked <0x0000000110a457a8> (a java.lang.Runtime)
>> at java.lang.System.load(System.java:1061)
>> at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>> at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1957)
>> - locked <0x0000000128bc39a8> (a java.util.Vector)
>> - locked <0x0000000128bc3610> (a java.util.Vector)
>> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1882)
>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1864)
>> at java.lang.Runtime.loadLibrary0(Runtime.java:849)
>> - locked <0x0000000110a457a8> (a java.lang.Runtime)
>> at java.lang.System.loadLibrary(System.java:1087)
>> at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:67)
>> at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:47)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at java.awt.Toolkit.loadLibraries(Toolkit.java:1646)
>> at java.awt.Toolkit.<clinit>(Toolkit.java:1668)
>> at sun.awt.AppContext$2.run(AppContext.java:271)
>> at sun.awt.AppContext$2.run(AppContext.java:260)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at sun.awt.AppContext.initMainAppContext(AppContext.java:260)
>> at sun.awt.AppContext.access$200(AppContext.java:133)
>> at sun.awt.AppContext$3.run(AppContext.java:316)
>> at sun.awt.AppContext$3.run(AppContext.java:298)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at sun.awt.AppContext.getAppContext(AppContext.java:297)
>> at javax.imageio.spi.IIORegistry.getDefaultInstance(IIORegistry.java:154)
>> at com.id.external.javax.media.jai.Services.register(Services.java:20)
>> at com.id.external.javax.media.jai.activator.Activator.start(Activator.java:26)
>> at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702)
>> at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683)
>> at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381)
>> at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:299)
>> at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:291)
>> at com.id.core.platform.repository.BundleRepository.startBundle(BundleRepository.java:486)
>> at com.id.core.platform.repository.BundleRepository.handleResolvedBundle(BundleRepository.java:389)
>> at com.id.core.platform.repository.BundleRepository.scanBundles(BundleRepository.java:269)
>> at com.id.core.platform.repository.BundleRepository.start(BundleRepository.java:118)
>> - locked <0x00000001259d7d20> (a java.lang.Object)
>> at com.id.core.platform.Platform.bootstrap(Platform.java:184)
>> - locked <0x00000001259d4000> (a java.lang.Object)
>> - locked <0x00000001259d3fe0> (a com.id.core.platform.Platform)
>> at com.id.core.platform.activator.Activator$1.run(Activator.java:77)
>> - locked <0x00000001259ce758> (a java.lang.Object)
>>
>> I've been looking in the source but not sure if those fixes are already in the jdk 1.7u forest.
>>
>> Erik Vanherck
>>
>> ________________________________
>>
>> Inventive Designers' Email Disclaimer:
>> http://www.inventivedesigners.com/email-disclaimer
>
>

________________________________

Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer

From artem.ananiev at oracle.com  Fri Jun 28 10:32:18 2013
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Fri, 28 Jun 2013 21:32:18 +0400
Subject: AppContext issue in Apple Java 6 -- same issue in Oracle Java 7?
In-Reply-To: <E53C2A00-7BDE-4FFC-A4DF-96DCAAB318B5@blackboard.com>
References: <mailman.1.1371927601.20815.macosx-port-dev@openjdk.java.net>
	<E8BEEA48-D12E-43D5-BE06-DFCBC6677998@blackboard.com>
	<48FF7D86-1A7C-4C99-BA97-B765CB02AE0C@gmail.com>
	<E53C2A00-7BDE-4FFC-A4DF-96DCAAB318B5@blackboard.com>
Message-ID: <51CDC8A2.2060708@oracle.com>



On 6/27/2013 8:25 PM, Doug Zwick wrote:
>
> On 2013-06-26, at 6:55 PM, Michael Hall wrote:
>
>> On Jun 26, 2013, at 5:46 PM, Doug Zwick wrote:
>>
>>> I have dug deeper into this, and we are somehow getting our code
>>> running on AWT-EventQueue-0 in the "main" ThreadGroup, and not on
>>> AWT-EventQueue-2 in the "javawsApplicationThreadGroup" group
>>
>> This is normal for applications, if not jws, maybe jws is running
>> more like platform app's now?
>> From my HalfPipe app.
>>
>> dojava
>> javax.swing.SwingUtilities.invokeLater(new Runnable() { public void
>> run() { System.out.println(Thread.currentThread() + " " +
>> javax.swing.SwingUtilities.isEventDispatchThread()); }});
>> Thread[AWT-EventQueue-0,6,main] true
>> dojava: done
>>
>> Although I was sort of remembering the AppKit thread being the
>> actual EDT? Must be a misremember there. You aren't showing a
>> deadlock. I think actual instances of stack crawls showing deadlock
>> would be more useful to go on if theres a problem. As I remember
>> there have been multiple AWT-EventQueue-# threads going back a long
>> time, these haven't been a deadlock problem previously that I
>> remember. Thread group I'm not sure how would apply?
>
> Stand-alone apps typically have only one Swing event thread,
> AWT-EventQueue-0. When running under Web Start, apps typically have
> had two (-0 and -1), up through Java 7u21. These seem to be bound to
> the two different AppContext instances present in JWS apps. I didn't
> look into which one was the "right" EDT for the web start app code in
> 7u21.
>
> Starting in 7u25, there are now three EDTs, -0, -1 and -2 that
> correspond to three different AppContexts. The threads of the process
> seem to be grouped in the same manner, with a thread group for each
> AppContext. As a heuristic, we can look at the ThreadGroup of the
> calling thread, and from that deduce which AppContext it is running
> in. AWT-EventQueue-0 seems bound to the "main" ThreadGroup (at least
> in our app), -1 seems bound to the "javawsSecurityThreadGroup"
> ThreadGroup, and -2 seems bound to the "javawsApplicationThreadGroup"
> ThreadGroup. There is also a "system" ThreadGroup, but that one has
> now AWT-EventQueue-x thread in it. The "javawsApplicationThreadGroup"
> group is where all our application threads are grouped (which is also
> new behaviour in 7u25, in 7u21 we had some threads running in
> "main"). "AppKit Thread" is a member of the "main" ThreadGroup. It
> looks like all native code callbacks on the AppKit thread will send
> any Runnables queued with SwingUtilities.invokeLater to
> AWT-EventQueue-0, and not AWT-EventQueue-2. This causes problems. The

This is a bug in eAWT, which uses SwingUtilities.invokeLater(), but 
should use SunToolkit.postEvent(AppContext, AWTEvent) or similar.

Thanks,

Artem

> most obvious one is deadlocks. We were often getting situations where
> both AWT-EventQueue-0 and AWT-EventQueue-2 were contesting the AWT
> Tree Lock. Since different code paths through Swing acquire locks in
> different orders relative to acquiring the Tree Lock, we readily
> wound up in a state where one EDT held the Tree Lock and was waiting
> for another lock, while the other EDT had that other lock and was
> waiting for the Tree Lock. The only way that can happen is if an
> event has been posted to the wrong EDT. If the different EDTs
> routinely contested the same AWT Tree Lock, JWS apps would always be
> deadlocking. The different AppContexts must provide independent
> Swing/AWT environments to ensure that this does not happen.
>
> However, the problem with menu items is worse than I first thought.
> In addition to the About, Preferences and Quit menu items calling
> back through the EAWT interface on the wrong thread, it turns out
> that EVERY menu item in the screen menu bar responds to mouse
> activation by posting the ActionListener.actionPerformed event to the
> wrong EDT, namely the EDT associated with the "main" thread group,
> and not the EDT associated with our application code. It is
> interesting to note that activation via accelerator key causes the
> event to be posted to the correct EDT.
>
> We are working around this by checking the ThreadGroup before queuing
> Runnables with SwingUtilities.invokeLater, and if the ThreadGroup of
> the calling thread is not the same ThreadGroup associated with our
> main application startup thread (which we cache at startup time), we
> instead queue the Runnable for a worker thread that is running in the
> correct ThreadGroup and AppContext, and have it then queue the
> Runnable onto the EDT. This works well for invokeLater, but is more
> of a pain for invokeAndWait calls. Our deadlocks seem to have
> disappeared.
>
> We appear to have a related issue with Apple's 1.6.0_51 build, where
> we cannot open windows in callbacks from screen menu bar menu items
> (or they open but their content does not paint). This does not appear
> to be an issue under 7u25.
>
>
> This email and any attachments may contain confidential and
> proprietary information of Blackboard that is for the sole use of the
> intended recipient. If you are not the intended recipient,
> disclosure, copying, re-distribution or other use of any of this
> information is strictly prohibited. Please immediately notify the
> sender and delete this transmission if you received this email in
> error.
>

From jia-hong.chen at oracle.com  Fri Jun 28 11:18:57 2013
From: jia-hong.chen at oracle.com (Johnny Chen)
Date: Fri, 28 Jun 2013 11:18:57 -0700
Subject: apple.awt.OSXImage in jdk6 and the image drawing pipeline
Message-ID: <A8700A67-5560-4AF4-95DC-48E9F7D5C4DC@oracle.com>

Hi,

We recently received a bug concerning a regression of jdk7 compared to Apple's jdk6.
The problem was that the Bi-cubic and Bi-linear rendering are slow.  Digging a little bit, it appears that Apple's jdk6
is using a special image instance, e.g., image=apple.awt.OSXImage at 6f9ec4ed, while jdk7/8 is using, e.g.,
image=sun.awt.image.ToolkitImage at 2d6df705, when it comes time to draw the image using Graphics2D.draw(image, ?.).

The sample program is putting a java.awt.Canvas subclass called ScaledImage inside a JPanel and doing the image drawing
inside the subclass' paint(Graphics g) method.  There is massive slowness in jdk7 compared to jdk6 with the above approach.
Now if I change the ScaledImage class to extend JComponent, instead of ScaledImage extends Canvas,
the response feels much better, although still slower.  Without access to the jdk6 source code, I can only guess that apple.awt.OSXImage
is a special kind of Image with much better acceleration on the Mac OS X platform for Canvas drawing and the associated
pipeline for image drawing does a better job than jdk7 for image rendering even on a lightweight component.

Can anyone enlighten me on the rationale for taking out the apple.awt.OSXImage class for macosx port
and whether there's anything similar to Apple jdk6's way of rendering image that we can do to speed things up?

Thanks,
Johnny Chen


From mik3hall at gmail.com  Fri Jun 28 14:18:37 2013
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 28 Jun 2013 16:18:37 -0500
Subject: AppContext issue in Apple Java 6 -- same issue in Oracle Java 7?
In-Reply-To: <51CDC8A2.2060708@oracle.com>
References: <mailman.1.1371927601.20815.macosx-port-dev@openjdk.java.net>
	<E8BEEA48-D12E-43D5-BE06-DFCBC6677998@blackboard.com>
	<48FF7D86-1A7C-4C99-BA97-B765CB02AE0C@gmail.com>
	<E53C2A00-7BDE-4FFC-A4DF-96DCAAB318B5@blackboard.com>
	<51CDC8A2.2060708@oracle.com>
Message-ID: <0BC7BAF3-17E0-4F7E-BD7B-0B7661C17CEA@gmail.com>

On Jun 28, 2013, at 12:32 PM, Artem Ananiev wrote:
> 
> This is a bug in eAWT, which uses SwingUtilities.invokeLater(), but should use SunToolkit.postEvent(AppContext, AWTEvent) or similar.
> 

This is the only place where invokeLater isn't thread safe?

Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter