/16 16:22, Anton Tarasov wrote:
>> Hi Pete,
>>
>> The fix looks fine to me.
>>
>> Thanks,
>> Anton.
>>
>> On 9/24/2016 2:59 AM, Pete Brunet wrote:
>>> New webrev:
>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8160893/webrev.02/
>>
OK. Looks good then.
On 9/27/16 8:37 AM, Anton Tarasov wrote:
> But it returns an array which is an object and you don’t have the original
> unboxing issue.
>
> Anton.
>
>> On 27 Sep 2016, at 15:57, Pete Brunet wrote:
>>
>> Anton, It looks like you need to also
Anton, It looks like you need to also update getInitialAttributeStates.
-Pete
On 9/16/16 12:49 PM, Anton Tarasov wrote:
> On 9/16/2016 1:32 PM, Sergey Bylokhov wrote:
>> On 15.09.16 14:48, Anton Tarasov wrote:
Yes, and my suggestion was to use the new method and default values
everywher
Looks good Alexandr.
On 4/29/16 11:42 AM, Alexander Scherbatiy wrote:
>
> Hello,
>
> Cold you review the updated fix:
> http://cr.openjdk.java.net/~alexsch/8017112/webrev.01
>
> The (this instanceof Accessible) is removed from the fix.
>
> Thanks,
> Alexandr.
>
> On 29/04/16 01:37, Serge
ect tmpLocalRef = NewLocalRef(weakGlobalRef)
>>>> if (IsSameObject(tmpLocalRef, NULL)) {
>>>> // return
>>>> }
>>>> // use tmpLocalRef
>>>> DeleteLocalRef(tmpLocalRef)
>>>>
>>>> Also, I discovered more ref
Hi Anton, Why did you change CAccessible.dispose() from protected to
public? Shouldn't it be left protected? -Pete
On 12/22/15 3:45 PM, Anton Tarasov wrote:
> Hi Pete,
>
> Thanks for the review!
>
>> On 22 Dec 2015, at 23:07, Pete Brunet > <mailto:peter.bru...@oracl
team). -Pete
On 12/22/15 3:45 PM, Anton Tarasov wrote:
> Hi Pete,
>
> Thanks for the review!
>
>> On 22 Dec 2015, at 23:07, Pete Brunet > <mailto:peter.bru...@oracle.com>> wrote:
>>
>> Hi Anton, Some comments/questions:
>> - Some copyright dates need up
Hi Anton, Some comments/questions:
- Some copyright dates need updating
- Line 1112 of JavaComponentAccessibility: does the release of
jaccessible cause a release of jparent?
- Line 7155 of Component.java: is that the only place where this means
is needed?
Pete
On 12/22/15 8:10 AM, Anton Tarasov
One final update from Mandy:
- change test path to remove jdk.accessibility; only use package name
for path
- add @modules java.desktop jdk.accessibility
http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.03/
Pete
On 7/16/15 8:48 PM, Pete Brunet wrote:
> From Mandy:
> - remove
Please review this patch which cures a problem that appears since 9 b58
when the compiler was switched to VS2013 and as a result turned on the
High Entropy Virtual Addresses bit in the executable header when running
on Win 8.1.
With the high-entropy 64-bit address space layout randomization optio
, Pete Brunet wrote:
> This is a JNI question. Is the JavaVM* pointer returned by GetJavaVM
> guaranteed to not have any bits in the upper 32?
>
> There is old code I am working with that stores the JavaVM pointer in
> longs (32 bits on 64 bit Win) and uses longs to transfer the val
This is a JNI question. Is the JavaVM* pointer returned by GetJavaVM
guaranteed to not have any bits in the upper 32?
There is old code I am working with that stores the JavaVM pointer in
longs (32 bits on 64 bit Win) and uses longs to transfer the value all
around within the code and to/from an
>From Mandy:
- remove unused imports
- add @run main/othervm
http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.02/
On 7/15/15 4:42 PM, Pete Brunet wrote:
> An update is available and mostly changes only the test case,
> Bug8151626.java. The other change is to remove jtreg.securi
nd of the test.
>
> On 14.07.15 1:34, Pete Brunet wrote:
>> Please review the webrev for
>> https://bugs.openjdk.java.net/browse/JDK-8051626
>>
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.00/
>>
>> This is so the the Java Accessibility U
Please review the webrev for
https://bugs.openjdk.java.net/browse/JDK-8051626
http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.00/
This is so the the Java Accessibility Utilities package,
com.sun.java.accessibility.util, can be run with the security manager
active but the non-public access
That fixed it. Thanks Semyon.
On 7/1/15 8:25 AM, Pete Brunet wrote:
> Thanks Semyon! I'll give it a try. -Pete
>
> On 7/1/15 2:29 AM, Semyon Sadetsky wrote:
>> Hi Pete,
>>
>> I heard that you got performance issue in b68 connected to text
>> co
t;
>
> On 6/29/2015 10:13 AM, Vadim Pakhnushev wrote:
>> I think './common/bin/hgforest bisect ...' should do the trick then.
>>
>> On 29.06.2015 7:30, Phil Race wrote:
>>>
>>> Just be aware that you will need to apply the same to each repo in
>>
the 'first bad' changeset.
> See here for reference: https://www.selenic.com/hg/help/bisect
>
> Hope this helps,
> Vadim
>
> On 28.06.2015 18:15, Pete Brunet wrote:
>> Looks like I can use hg update to accomplish this, i.e. hg update to the
>> rev that is b67 a
Looks like I can use hg update to accomplish this, i.e. hg update to the
rev that is b67 and then hg update to each possibly offending rev of the
jdk repo. Sound right?
On 6/26/15 4:13 PM, Pete Brunet wrote:
> Hi, I found a problem on b68 and there are a half dozen possible
> changeset
Hi, I found a problem on b68 and there are a half dozen possible
changesets that could be responsible. What is the best way to do the
process of elimination. It seems like the right approach would be to
start with b67 and then add changesets one at a time until the problem
surfaces. Is that righ
Thanks Sergey. awt-dev team I need one more +1
On 6/18/15 9:15 AM, Sergey Bylokhov wrote:
> Looks fine.
>
> On 17.06.15 20:09, Pete Brunet wrote:
>> Hi, I need a review of a very simple fix, changing {@code(...)} to
>> {@code ...}
>>
>> http://cr.openjdk.java.ne
Hi, I need a review of a very simple fix, changing {@code(...)} to
{@code ...}
http://cr.openjdk.java.net/~ptbrunet/JDK-8114861/webrev.00/
Thanks, Pete
Thanks Mandy, The new patch is at
http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.04
On 6/10/15 6:29 PM, Mandy Chung wrote:
>> On Jun 10, 2015, at 3:33 PM, Pete Brunet wrote:
>>
>> Due to some other priorities it's been over 2 months since the last webrev.
>&g
Thanks Mandy.
I need one more review from the awt-dev team.
Pete
On 6/10/15 6:29 PM, Mandy Chung wrote:
>> On Jun 10, 2015, at 3:33 PM, Pete Brunet wrote:
>>
>> Due to some other priorities it's been over 2 months since the last webrev.
>> An update is here:
inked in windows image at the
> moment. It is a bug. Are you going to fix that in this changeset? I think
> you have to verify this change in windows as well as other platforms.
>
> Mandy
>
>
>> On Jun 10, 2015, at 3:33 PM, Pete Brunet wrote:
>>
>> Due to s
Note that I need to remove the import of java.io.PrintWriter in
java.awt.Toolkit.java
On 6/10/15 5:33 PM, Pete Brunet wrote:
> Due to some other priorities it's been over 2 months since the last
> webrev. An update is here:
> http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/web
vider. Instead a file is created when
Toolkit.getDefaultToolkit activates providers and tested for existence
when the test runs.
2) The copyright header in the new jdk.accessibility files were fixed.
Pete
On 4/3/15 3:59 PM, Pete Brunet wrote:
> Due to the recent push of JDK-8076182 (Open source Jav
On 6/5/15 1:06 AM, David Holmes wrote:
> Hi Peter,
>
> On 5/06/2015 4:01 PM, Pete Brunet wrote:
>> Hi, When I run java from the command line I can tell my code in
>> java.awt.Toolkit.getDefaultToolkit is running but when I run in a JTREG
>> environment I don't see
Please review the following change for 8u:
http://cr.openjdk.java.net/~ptbrunet/JDK-8077296/webrev.00/
Background:
- As part of the open sourcing of the JAB and Java Accessibility
Utilities (JAU) the JAU Javadoc was setup to be added to the build.
- Due to a 8u build issue (it uses source bundles
Resending to correct list...
On 5/8/15 2:11 PM, Pete Brunet wrote:
> Please review the fix for JDK-8078408 "Java version applet hangs with
> Voice over turned on".
>
> The failure is an NPE. There is a variable that is OK to be null at the
> point of failure and the fix
>
> Do you have a forest on nfs? (from where I can pull/clone your fixes)?
>
> - Lana
>
>
> On 04/08/2015 11:08 AM, Pete Brunet wrote:
>> I confirmed the javadoc is gone, and make docs did not fail.
>>
>> I have yet to submit the JPRT job.
>>
>&g
:
> That looks good to me.
>
> -phil.
>
> On 4/8/2015 10:55 AM, Pete Brunet wrote:
>> How's this?
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.03
>>
>> On 4/8/15 12:47 PM, Mandy Chung wrote:
>>> I agree with Phil's suggesti
I added 9-na.
>
> Rule 4. Approval requests should be carried out on jdk8u-dev mailing
> list.
I did the RfA on jdk8u-dev (but am pending the start/run/success of the
7 JPRT builds).
>
> regards,
> Sean.
>
> On 08/04/2015 19:14, Pete Brunet wrote:
>> resending - too man
resending - too many on To:/Cc:
On 4/8/15 1:08 PM, Pete Brunet wrote:
> I confirmed the javadoc is gone, and make docs did not fail.
>
> I have yet to submit the JPRT job.
>
> Sean/Winston do you want to wait for the 7 JPRT jobs to finish before
> you approve the push?
>
&
enerated for this package on windows build.
>
> Mandy
>
> On 4/8/2015 10:29 AM, Phil Race wrote:
>> Isn't it sufficient to comment out this one line ?
>>
>> 1215 ALL_OTHER_TARGETS += jaccessdocs
>>
>> .. and add a comment as to why ?
>>
>&g
t will work I'll redo the patch. Let me know.
>
> -phil.
>
>
> On 04/08/2015 10:25 AM, Pete Brunet wrote:
>> Here is an updated patch.
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.02/
>>
>> It simply removes the com.sun.java.accessibility.
approval.
I have started a local Win build and will start JPRT builds on Linux,
Windows, Solaris, and Mac shortly.
Thanks,
Pete
On 4/8/15 12:51 AM, Pete Brunet wrote:
> Please review/approve the following patch.
>
> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/
>
> The
David, Considering that the source should be in jdk/src/share/classes
does that change things? -Pete
>
> David
>
> On 8/04/2015 3:51 PM, Pete Brunet wrote:
>> Please review/approve the following patch.
>>
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/
ndy
>
> On 4/7/2015 10:51 PM, Pete Brunet wrote:
>> Please review/approve the following patch.
>>
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/
>>
>> The recent push for JDK-8076182 caused a build break, i.e. a problem for
>> the creation
Please review/approve the following patch.
http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/
The recent push for JDK-8076182 caused a build break, i.e. a problem for
the creation of the Javadoc in the environment used by the nightly
build. This was because a newly opened package
com.su
Chung wrote:
>
>
> On 3/19/2015 6:03 PM, Pete Brunet wrote:
>> A new webrev is available at
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.01/
>>
>
> line 820-821: this comment is incorrect.
>
> line 831-838: what happens if ServiceConfigurationE
that its safe
> to remove that copy for closed builds anyway
>
> I think the safe thing to do is undo that change in Copy-java.gmk
> and leave the closed file in place and discuss off-line with the
> security team why the files differ ..
I'll start a discussion on this.
>
Hi Sergey, Which methods are you referring to? -Pete
On 3/25/15 10:16 AM, Sergey Bylokhov wrote:
> The fix looks fine.
> But it is interesting, do we have an option to remove all deprecated
> methods during this opening? or can we do it later? or we cannot?
>
> 25.03.15 17:44, Pe
ild so no
> reason to remove them.
Thanks Erik, My build and tests ran OK so apparently they are no longer
needed.
To all: My hope is to push this patch into 9 tomorrow (Thursday) so
please let me know if there are any additional issues as soon as you can.
Pete
>
> /Erik
>
> On
On 3/24/15 3:23 PM, Pete Brunet wrote:
> Hi Sergey, That's pretty much the case. I just went through the code
> and found these differences:
> - merged in JDK-8055173 (merge jawt.dll into javaaccessbridge.dll) which
> was recently pushed.
That should have been jawtaccessbridge.
t and Monkey test tools which will be
the subject of a later patch
- removed the DEF files; although they were used in the build, there are
no build or runtime problems after their removal
On 3/24/15 8:08 AM, Magnus Ihse Bursie wrote:
> On 2015-03-23 18:31, Pete Brunet wrote:
>> Hi Erik,
understand correctly that the code itself were not changed except
> files location?
>
> 21.03.15 7:33, Pete Brunet wrote:
>> Please review the following patch which will add the code of the Java
>> Access Bridge (JAB) and related Java Accessibility Utilities to OpenJDK.
>
ridge.DEF is pretty empty. I'll see if the build will work
without it.
WinAccessBridge.DEF seems like it might be needed. What do you think?
Pete
>
> /Erik
>
> On 2015-03-21 05:33, Pete Brunet wrote:
>> Please review the following patch which will add the code of the
Please review the following patch which will add the code of the Java
Access Bridge (JAB) and related Java Accessibility Utilities to OpenJDK.
This code is used by Assistive Technology such as screen readers and
screen magnifiers used by those who are blind or have low vision. AT
use the JAB nati
viders but
only one is activated." If not, please let me know.
Pete
On 3/17/15 4:24 PM, Pete Brunet wrote:
>
>
> On 3/17/15 3:51 PM, Pete Brunet wrote:
>> Hi Alan, Thanks for the review.
>>
>> On 3/17/15 3:42 AM, Alan Bateman wrote:
>>> On 17/03/2015 01:14
On 3/17/15 3:51 PM, Pete Brunet wrote:
> Hi Alan, Thanks for the review.
>
> On 3/17/15 3:42 AM, Alan Bateman wrote:
>> On 17/03/2015 01:14, Mandy Chung wrote:
>>>
>>> On 3/16/2015 1:52 PM, Pete Brunet wrote:
>>>> The following patch to accessib
Hi Alan, Thanks for the review.
On 3/17/15 3:42 AM, Alan Bateman wrote:
> On 17/03/2015 01:14, Mandy Chung wrote:
>>
>> On 3/16/2015 1:52 PM, Pete Brunet wrote:
>>> The following patch to accessibility related code is for the modularity
>>> effort.
>>>
&g
Please ignore the request for the pubs change. I removed it from the
server.
On 3/16/15 4:16 PM, Pete Brunet wrote:
> Also, there is a related pubs change. The documentation for defining
> the assistive_technolgies property needs to change from defining a class
> name to defining
Also, there is a related pubs change. The documentation for defining
the assistive_technolgies property needs to change from defining a class
name to defining a service provider name. See
http://cr.openjdk.java.net/~ptbrunet/JDK-8074722/webrev.00/
On 3/16/15 3:52 PM, Pete Brunet wrote:
>
The following patch to accessibility related code is for the modularity
effort.
http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.00/
The Java Access Bridge (which provides access to Java for example by
screen readers used by those who are blind) is currently loaded by
Toolkit via reflectio
Thanks Alexandr.
So far Alexandr is the only reviewer of this. I'd like one more.
Thanks, Pete
On 5/23/14 5:34 AM, Alexander Scherbatiy wrote:
> On 5/22/2014 9:59 PM, Pete Brunet wrote:
>> I'd like one more reviewer of this fix.
>>
>> Also I removed the @Deprecat
I'd like one more reviewer of this fix.
Also I removed the @Deprecated and will deal with this in a following
JBS issue.
http://cr.openjdk.java.net/~ptbrunet/JDK-8009883/webrev.04/
Pete
On 5/21/14 10:08 AM, Pete Brunet wrote:
> On 5/21/14 7:04 AM, Alexander Scherbatiy wrote:
>>
On 5/21/14 7:04 AM, Alexander Scherbatiy wrote:
> On 5/21/2014 2:56 PM, Alexander Scherbatiy wrote:
>> On 5/20/2014 1:10 AM, Pete Brunet wrote:
>>> On 5/16/14 11:04 AM, Pete Brunet wrote:
>>>> On 5/16/14 10:45 AM, Alexander Scherbatiy wrote:
>>>>
On 5/16/14 11:04 AM, Pete Brunet wrote:
> On 5/16/14 10:45 AM, Alexander Scherbatiy wrote:
>> On 5/16/2014 7:15 PM, Pete Brunet wrote:
>>> On 5/16/14 6:45 AM, Alexander Scherbatiy wrote:
>>>>Hi Peter,
>>>>
>>>>Is ther
On 5/16/14 10:45 AM, Alexander Scherbatiy wrote:
> On 5/16/2014 7:15 PM, Pete Brunet wrote:
>> On 5/16/14 6:45 AM, Alexander Scherbatiy wrote:
>>>Hi Peter,
>>>
>>>Is there any difference between AccessibleAWTFocusHandler and
>>> AccessibleFoc
if (accessibleContext != null) {
accessibleContext.firePropertyChange(
AccessibleContext.ACCESSIBLE_STATE_PROPERTY,
AccessibleState.FOCUSED, null);
}
}
}
>
> Thanks,
> Alexandr.
>
Hi Swing and AWT teams, (and Artem since you were involved in the
7179482 fix),
I'd appreciate your review for a fix to a regression in
java.awt.Component and javax.swing.JComponent.
Original bug: https://bugs.openjdk.java.net/browse/JDK-7179482
Orignal CCC: 7179482
Regression Bug: https://bugs.o
It's been two or three weeks since I last built 9 on macosx but I
started rebuilding yesterday and am getting random failures in the jdk
build:
Twice I got this:
Compiling 225 files for BUILD_SECURITY
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation
>
> With best regards. Petr.
>
> 14 марта 2014 г., в 10:45 после полудня, Pete Brunet
> написал(а):
>
>> On 3/14/14 1:22 PM, Petr Pchelko wrote:
>>> Hello, Peter.
>>>
>>> Simply writing to System.out or System.err without any logger doesn’t wor
> With best regards. Petr.
>
> 14 марта 2014 г., в 10:18 после полудня, Pete Brunet
> написал(а):
>
>> Hi I am debugging in an applet environment and woudl like to log ot the
>> Java Console. I tried the following (from StackOverflow) with no luck:
>>
Hi I am debugging in an applet environment and woudl like to log ot the
Java Console. I tried the following (from StackOverflow) with no luck:
Logger log = Logger.getLogger("my.logger");
log.setLevel(Level.ALL);
ConsoleHandler handler = new ConsoleHandler();
handler.setFormatter(new Simpl
Where is the right place to get a review of my test case? I'll post it
here a bit later if there's not a better idea.
On 12/18/13 2:01 PM, Pete Brunet wrote:
> On 12/18/13 1:22 PM, Pete Brunet wrote:
>> On 12/18/13 1:15 PM, Pete Brunet wrote:
>>> On 12/18/13 3:24 AM,
On 12/18/13 1:22 PM, Pete Brunet wrote:
> On 12/18/13 1:15 PM, Pete Brunet wrote:
>> On 12/18/13 3:24 AM, Artem Ananiev wrote:
>>> On 12/17/2013 10:42 PM, Pete Brunet wrote:
>>>> Hi Anthony, Thanks again for the assistance!
>>>>
>>>> On 12
On 12/18/13 1:15 PM, Pete Brunet wrote:
> On 12/18/13 3:24 AM, Artem Ananiev wrote:
>> On 12/17/2013 10:42 PM, Pete Brunet wrote:
>>> Hi Anthony, Thanks again for the assistance!
>>>
>>> On 12/17/13 7:29 AM, Anthony Petrov wrote:
>>>>> Immediate
On 12/18/13 3:24 AM, Artem Ananiev wrote:
>
> On 12/17/2013 10:42 PM, Pete Brunet wrote:
>> Hi Anthony, Thanks again for the assistance!
>>
>> On 12/17/13 7:29 AM, Anthony Petrov wrote:
>>>> Immediate load in JAWT*, delay load in Java*
>>>
K doesn't support WinRT currently. The JAWT* (or any binary in JDK)
> just shouldn't be linked against these libraries (and probably other
> API-MS-*, too). Where do the dependencies come from? What does your
> Makefile do to link the JAWT* lib?
>
> --
> best regards,
>
mshtml.dll
API-MS-WIN-CORE-WINRT-L1-1-0.DLL and
API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
>
> --
> best regards,
> Anthony
>
> On 12/17/2013 12:44 AM, Pete Brunet wrote:
>> Hi Anthony, Thanks for helping...
>>
>> On 12/16/13 1:32 PM, Anthony Petrov wr
On 12/16/13 2:44 PM, Pete Brunet wrote:
> Hi Anthony, Thanks for helping...
>
> On 12/16/13 1:32 PM, Anthony Petrov wrote:
>> Hi Pete,
>>
>> I see you've already tried the Dependency Walker.
>>
>> 1. Could you please clarify the following: if you c
.DLL
WINNSI.DLL
WINSCARD.DLL
WINSPOOL.DRV
WINSTA.DLL
WINTRUST.DLL
WKSCLI.DLL
WLANAPI.DLL
WLANUTIL.DLL
WLDAP32.DLL
WS2_32.DLL
WTSAPI32.DLL
XMLLITE.DLL
>
> --
> best regards,
> Anthony
>
> On 12/16/2013 08:02 PM, Pete Brunet wrote:
>> I'm writing a regression test and it is
I'm writing a regression test and it is failing trying to load
bin\JAWTAccessBridge.DLL. It was successful in loading
bin\JavaAccessBridge.dll just prior to the failure. These two DLLs are
in jre\bin. Here's the failure:
java.lang.UnsatisfiedLinkError:
C:\\Users\\Pete\\JDK8\\JDK-8029691\\jdk8\\
Hi Serge, Maybe Peter Korn remembers.
On 9/29/13 4:11 PM, Sergey Bylokhov wrote:
> Hello, Artem, Peter.
> Our TextComponent class has a few methods related to the
> accessibility, which are never used:
> int getIndexAtPoint(Point p) {}
> Rectangle getCharacterBounds(int i) {}
>
> All of them are u
Subject: Please review fix for 7179482 :
Component.accessibleContext and JComponent.accessibleContext refactoring
Date: Fri, 09 Nov 2012 15:27:33 -0600
From: Pete Brunet
Reply-To: peter.bru...@oracle.com
To: awt-dev , swing-...@openjdk.java.net
Please review the
This bug includes a coordination of fixes for both awt (2 files) and
swing (1 file). Which repo should I use? jdk8/awt or jdk8/swing? I'm
guessing the latter. (AccessibleJComponent inherits from
AccessibleAWTContainer).
Pete
On 11/9/12 3:27 PM, Pete Brunet wrote:
> Please re
Please review the following fix planned for JDK8. Part of the fix will
go into 7u12 under 7177111.
Problem:
In the process of evaluating 7177111 the following problems were noticed:
- Both Component and JComponent have field "accessibleContext". In
Component it is package-private and accessed by
Hi Everyone, Please review the following fix planned for 7u12. It will
also go into 8 under 7179482.
Problem:
When an AT (Assistive Technology) accesses a Java application with
several nested frames, too many property change listeners are added
resulting in a severe performance impact for an AT u
There is something about a patch I am working on that results in a hang
when exiting an app with a fastdebug build but not with a product
build. The results of ctrl+break follow. Could someone look at this
and give me a hint as to what the deadlock is? Thanks, Pete
Full thread dump OpenJDK Clie
I found awt.map. That gets me pretty close.
Pete Brunet wrote:
> How do I determine where awt code is from an hs_err log? Here is a
> trace I am trying to decipher:
>
> C [OLEACC.dll+0x29dc8]
> C [OLEACC.dll+0xb94b]
> C [OLEACC.dll+0xc03d]
> C [OLEACC.dll+0xc704]
&g
How do I determine where awt code is from an hs_err log? Here is a
trace I am trying to decipher:
C [OLEACC.dll+0x29dc8]
C [OLEACC.dll+0xb94b]
C [OLEACC.dll+0xc03d]
C [OLEACC.dll+0xc704]
C [OLEACC.dll+0xc7f1]
C [OLEACC.dll+0x25af5]
C [OLEACC.dll+0x25c72]
C [jhook.dll+0x1611b]
C [USER32.d
Got it working. Using GetClass and toString helped me see that I was
passing the wrong kind of object as a parameter across the JNI
boundary. -Pete
Pete Brunet wrote:
> p.s. I tried the various JNI -XX switches listed here, at least the ones
> that made sense to try in my situation:
p.s. I tried the various JNI -XX switches listed here, at least the ones
that made sense to try in my situation:
http://www.md.pp.ru/~eu/jdk6options.html
Pete Brunet wrote:
> I'm looking for guidance in how to debug the following jvm assert
> failure. I've tried both -Xcheck:jni
I'm looking for guidance in how to debug the following jvm assert
failure. I've tried both -Xcheck:jni and -verbose:jni but neither of
those added any information at the point of failure. Thanks, Pete
# Internal Error
(c:\OpenJDK-b96m\jdk7\hotspot\src\share\vm\interpreter\linkResolver.cpp:71),
for what I'm logging I also need to wait for the
first window - my code runs in lib\ext.)
I asked a few people/lists about this so ccing those for awareness that
my logging is now working.
Pete
===
Christian Thalinger wrote:
> On Thu, 2010-07-08 at 09:12 -0500, Pete Brunet wrote:
>
e very top Makefile of the forest uses the jdk/make/Makefile and by
> default does both the
> 'all' and 'images' targets, but also redirects the default output
> directory to the top level.
> So depending on what directory in the forest you are in, the default
>
g
Thanks, Pete
===
Kelly O'Hair wrote:
> Maybe you should try the awt alias.
>
> I would assume you could do a full build, then 'cd make/sun.awt &&
> make' to just
> re-build awt, but you need to ask the awt engineers.
>
> -kto
>
> On Jun 28, 2010, at
I am using a System.out.println in code running from lib/ext, but the
text is not showing up on the console from which java.exe was launched.
Is this a known issue and is there a workaround? Thanks, Pete
I tried to use the existing NetBeans awt2d project in the OpenJDK JDK7
netbeans directory but it doesn't work with the current build
configuration and I've been told the maintainer left Sun quite some time
ago. I need to get started debugging my Java code and would like to get
NetBeans project fil
ust go into
> jdk/make/sun/awt, execute you script and rebuild only platform
> specific AWT code.
>
> Thank you,
>Denis.
>
> On 6/29/10 4:01 AM, Pete Brunet wrote:
>> Looking for a confirmation of Kelly's advice...
>>
>> Kelly O'Hair wrote:
>>
Looking for a confirmation of Kelly's advice...
Kelly O'Hair wrote:
> Maybe you should try the awt alias.
>
> I would assume you could do a full build, then 'cd make/sun.awt &&
> make' to just
> re-build awt, but you need to ask the awt engineers.
>
93 matches
Mail list logo
