sysroots and tool-chains and dev-kits! oh my!
Seriously, what does all this mean for someone who just wants to build
the OpenJDK? I use dev-kit for cross-compilation builds but I have no
idea what these different things are supposed to represent.
David
On 26/03/2014 8:32 PM, Erik Joelsson wr
On 26/03/2014 9:57 PM, Magnus Ihse Bursie wrote:
On 2014-03-26 12:51, David Holmes wrote:
sysroots and tool-chains and dev-kits! oh my!
Seriously, what does all this mean for someone who just wants to build
the OpenJDK? I use dev-kit for cross-compilation builds but I have no
idea what these
The fix that was pushed for this does not compile:
/opt/jprt/T/P1/053347.jdeploy/s/jdk/src/java.desktop/share/classes/java/awt/Robot.java:565:
error: unexpected type
if (AccessController.doPrivileged(OSInfo.getOSTypeAction())
= OSInfo.OSType.MACOSX) {
On 15/01/2015 6:23 AM, David DeHaven wrote:
Can someone from hotspot-dev please look at the hotspot changes?
Looks okay to me.
Thanks,
David H.
-DrD-
Hello,
This looks good to me. Thanks for the detailed table!
/Erik
On 2015-01-14 04:09, David DeHaven wrote:
The --with-xcode-path argu
Pete,
I think Erik's suggestion in the bug report is more appropriate. If this
is only a source bundle issue then the build instructions for javadoc
should either be Windows specific, or else check for source existence.
David
On 8/04/2015 3:51 PM, Pete Brunet wrote:
Please review/approve th
Hi Pete,
Sorry all this was happening in the wee hours for me :)
On 9/04/2015 3:55 AM, Pete Brunet wrote:
How's this?
http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.03
Seems like a good temporary fix.
To answer your earlier question to my comment, the $60K question is
whether this
Including awt-dev.
David
On 12/06/2015 3:04 AM, Vladimir Kozlov wrote:
First, we should let people know about this. (I don't know client-lib
mailing list).
Fortunately 8075505 is AWT backport bug which was fixed already. 8075505
will not appear in changeset since we use main bug id in backport
Hi Folks,
I'm currently looking at some hotspot cleanup surrounding the
ConvertSleepToYield VM flag. When this flag is true it replaces a call
to Thread.sleep(0) with a platform yield call; otherwise the platform
"sleep" function is called with sleep time of 1ms. (Note: no reasonable
Java cod
The bug report for this is confidential but quite simply all of the
little tweaks and knobs we added to the open build and source files to
support the Java SE Embedded product no longer need to be there for JDK
9. Many of them have already been removed via other changes but this
cleans up the r
Thanks for the review Alan!
David
On 15/07/2016 6:52 AM, Alan Bateman wrote:
On 14/07/2016 05:25, David Holmes wrote:
The bug report for this is confidential but quite simply all of the
little tweaks and knobs we added to the open build and source files to
support the Java SE Embedded
Thanks for the review Paul!
David
On 14/07/2016 11:12 PM, Paul Sandoz wrote:
On 14 Jul 2016, at 06:25, David Holmes wrote:
The bug report for this is confidential but quite simply all of the little
tweaks and knobs we added to the open build and source files to support the
Java SE
Can I please get someone from AWT to approve this.
Thanks,
David
On 14/07/2016 2:25 PM, David Holmes wrote:
The bug report for this is confidential but quite simply all of the
little tweaks and knobs we added to the open build and source files to
support the Java SE Embedded product no longer
Thanks Alexandr!
David
On 19/07/2016 9:26 PM, Alexandr Scherbatiy wrote:
The fix looks good to me.
Thanks,
Alexandr.
On 7/16/2016 2:55 AM, David Holmes wrote:
Can I please get someone from AWT to approve this.
Thanks,
David
On 14/07/2016 2:25 PM, David Holmes wrote:
The bug report for
sadebugd.pdb mlib_image.dllsawindbg.pdb
WindowsAccessBridge-32.dll
fontmanager.pdb JavaAccessBridge.dll jconsole.pdb
jsdt.dll mlib_image.pdbschemagen.exe
WindowsAccessBridge-32.pdb
freetype.dll ...
So maybe a problem with paths? or this .pdb file missing for
freetype.dll? not
Hi Matthias,
On 13/08/2018 4:41 PM, Baesken, Matthias wrote:
Thank‘s !
Can I have a second review please ?
As the build team seem to be on vacation right now I can add that second
Review. :)
Cheers,
David
Best regards, Matthias
From: Phil Race
Sent: Freitag, 10. August 2018 20:12
To: B
Hi Matthias,
On 17/12/2018 11:12 pm, Baesken, Matthias wrote:
Hello, please review
http://cr.openjdk.java.net/~mbaesken/webrevs/8215296.0/
in my change just -xc99=%none is removed, so we do not forbid c99 coding.
The -Xa compile flag is kept, no special additional settings are needed to
Our internal builds pass okay.
David
On 18/12/2018 8:02 am, David Holmes wrote:
Hi Matthias,
On 17/12/2018 11:12 pm, Baesken, Matthias wrote:
Hello, please review
http://cr.openjdk.java.net/~mbaesken/webrevs/8215296.0/
in my change just -xc99=%none is removed, so we do not forbid c99
t main() {
bool b = true;
if (b) {
printf("b is true.\n");
}
// C++ style comments
// decl.
int a = 1;
printf("a: %d \n", a);
return 0;
}
Best regards, Matthias
-Original Message-
From: David Holmes
Sent: Dienstag, 18. Dezemb
flag change that relates to the source language used and
the build is fine so I don't see there are any issues. My own tests had
no new issues in our tiers 1 - 3.
Cheers,
David
Best regards, Matthias
-Original Message-
From: David Holmes
Sent: Dienstag, 18. Dezember 2018 09:
Correction: jdk-submit does test Solaris.
David
On 18/12/2018 8:02 am, David Holmes wrote:
Hi Matthias,
On 17/12/2018 11:12 pm, Baesken, Matthias wrote:
Hello, please review
http://cr.openjdk.java.net/~mbaesken/webrevs/8215296.0/
in my change just -xc99=%none is removed, so we do not
On 20/12/2018 1:31 am, Baesken, Matthias wrote:
Sounds like a simpler change, at least for now. Does it pass jdk-submit?
Hello Magnus , pushed it to jdk/submit , however I do not expect much info
from it because David told me Solaris is not tested there
I was incorrect.
(and the
m all -
myself included.
On Mon, Mar 25, 2019 at 1:34 AM David Holmes <mailto:david.hol...@oracle.com>> wrote:
Hi Thomas,
A few queries, comments and concerns ...
On 25/03/2019 6:58 am, Thomas Stüfe wrote:
> Hi all,
>
> After a long time I tried to b
Hi Gerard,
On 14/11/2019 6:05 am, Langer, Christoph wrote:
Hi Gerard,
generally it looks like a nice cleanup.
I've got a patch prepared though, which I was planning on posting tomorrow. It
is about cleanup for the canonicalize function in libjava. I wanted to use
jdk_util.h for the function
laris/Windows were not.
The .c file can go. The .h file wouldn't be empty as it still has the
other includes.
David
cheers
On 11/13/19 9:21 PM, David Holmes wrote:
Hi Gerard,
On 14/11/2019 6:05 am, Langer, Christoph wrote:
Hi Gerard,
generally it looks like a nice cleanup.
I'
Hi Sergey,
I've looked at the hotspot files. Changes seem okay, though for the
files with dual-copyrights it isn't clear whether the Oracle copyright
or other copyright should be updated for any given change. But it seems
to me that if anyone wants their specific copyright updated then it is
On Thu, 10 Sep 2020 10:40:15 GMT, Alan Bateman wrote:
>> @kevinrushforth thanks. Done.
>>
>> Similar issues:
>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8215014
>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8251246
>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=822
On Thu, 10 Sep 2020 12:18:51 GMT, Kevin Rushforth wrote:
>> This should be broken up to deal with the files in different functional
>> areas under different bugids and PRs. Otherwise
>> the cross-posting to so many lists is prohibitive. Files in different areas
>> need to be reviewed by differe
On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee wrote:
> Please review this small patch to enable the OSX build using Xcode 12.0.
>
> Thanks,
> Paul
Changes requested by dholmes (Reviewer).
src/hotspot/share/runtime/sharedRuntime.cpp line 2851:
> 2849: if (buf != NULL) {
> 2850: Cod
On 10/09/2020 10:07 pm, Dmitriy Dumanskiy wrote:
On Thu, 10 Sep 2020 11:21:28 GMT, David Holmes wrote:
The code in java.base was updated to use String::isEmpty in JDK 12
(JDK-8215281). There was follow-up in JDK 13 to do
the same in the java.desktop module (JDK-8223237). Changing the
On Tue, 20 Oct 2020 08:17:27 GMT, Sergey Bylokhov wrote:
> In some files, the copyright text is styled as a JavaDoc comment.
> Most of the affected files are tests, only one product file is affected:
> src/java.sql/share/classes/javax/sql/package-info.java
>
> The chenge is trivial:
> - /**
>
On 16/03/2021 11:58 am, Sergey Bylokhov wrote:
On Sun, 14 Mar 2021 23:34:55 GMT, Henry Jen wrote:
This patch ensure launcher won't crash JVM for the new static Methods from
local/anonymous class on MacOS.
As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug when
the lau
On 16/03/2021 2:59 pm, David Holmes wrote:
On 16/03/2021 11:58 am, Sergey Bylokhov wrote:
On Sun, 14 Mar 2021 23:34:55 GMT, Henry Jen wrote:
This patch ensure launcher won't crash JVM for the new static Methods
from local/anonymous class on MacOS.
As @dholmes-ora pointed out i
On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang wrote:
> Please review the test changes for [JEP
> 411](https://openjdk.java.net/jeps/411).
>
> With JEP 411 and the default value of `-Djava.security.manager` becoming
> `disallow`, tests calling `System.setSecurityManager()` need
> `-Djava.secu
This fix still makes me uncomfortable because flush() is not thread-safe
any more. If two threads can flush() then the first can clear the
isFlushing state (in the finally block) that has been set by the second
(in the synchronized block).
David
On 24/07/2012 9:42 PM, Peter Levart wrote:
Hi
d call of PostEventQueue.flush().
Yes but it is that undocumented indirection that concerns me. If someone
decides to remove those outer locks they may not realize there is a
lurking race here.
David
Thanks,
Oleg
7/26/2012 4:08 PM, David Holmes wrote:
This fix still makes me uncomfortable beca
Hi Anthony,
I took a look at the last incarnation of this so let me see if I can
follow the new scheme.
On 29/08/2012 9:08 PM, Anthony Petrov wrote:
Hi Oleg,
I'm still concerned about the following:
detachDispatchThread()
{
flush();
lock();
// possibly detach
unlock();
}
at EventQueue.java
Anthony Petrov wrote:
Hi David,
On 8/29/2012 3:45 PM, David Holmes wrote:
I took a look at the last incarnation of this so let me see if I can
follow the new scheme.
On 29/08/2012 9:08 PM, Anthony Petrov wrote:
Hi Oleg,
I'm still concerned about the following:
detachDispatchThrea
Hi Oleg,
It seems to me that the original code has the
isFlushingPendingEvents = false;
in the wrong place: it should only ever be cleared by an invocation that
set it. So a simple reorganization of the code would achieve that:
553 public static void flushPendingEvents() {
554
/7u10/7188708.2/
Thanks,
Oleg
9/7/2012 3:36 PM, David Holmes wrote:
Hi Oleg,
It seems to me that the original code has the
isFlushingPendingEvents = false;
in the wrong place: it should only ever be cleared by an invocation
that set it. So a simple reorganization of the code would achieve that
Hi Oleg,
I can't really comment on the higher-level logic/protocol here as I
can't track which thread does what, where and when.
In EventQueue.java this comment is no longer valid:
* Fix for 4648733. Check both the associated java event
* queue and the PostEventQueue.
*/
!
On 11/09/2012 1:17 AM, Artem Ananiev wrote:
On 9/10/2012 6:50 PM, Anthony Petrov wrote:
On 09/10/12 15:27, Artem Ananiev wrote:
** This is safe because a thread only ever writes its own value to
flushThread so even if it reads a stale value that value will either be
null or some other thread -
the fact
it works properly.
Thanks,
Oleg
9/10/2012 3:27 PM, Artem Ananiev wrote:
Hi, David,
see my comments inline.
On 9/8/2012 4:44 AM, David Holmes wrote:
Hi Oleg,
I can't really comment on the higher-level logic/protocol here as I
can't track which thread does what, where and wh
Minor typo in the gmk file
32 # These are the once used.
once -> ones
Thanks,
David
On 19/01/2013 12:05 AM, Erik Joelsson wrote:
Here is a new webrev with my sorts incorporated. This has been baking
for quite a while in build-infra now and seems to be working.
http://cr.openjdk.java.net/~er
Hi Erik,
I need this pushed to jdk8/build yesterday! :) Seriously!
This is now a blocker for the Profiles integration work. I thought I was
utilizing 8005855 as a workaround but it never got pushed - instead I
still have my hack of deleting the X_LIBS and X_CFLAGS from the sizer
build. I can'
Adding core-libs as this is actually a launcher change.
David
On 21/05/2013 4:36 PM, Petr Pchelko wrote:
Hello, AWT Team.
Please review the fix for the issue:
http://bugs.sun.com/view_bug.do?bug_id=8009911
The webrev is available at:
http://cr.openjdk.java.net/~pchelko/8009911/webrev.00/
The
On 15/10/2013 5:19 AM, Daniel Fuchs wrote:
Adding awt-dev...
The change looks okay to me but I would suggest sending to awt-dev so
that the folks that maintain this area know about it.
On the test then does initializing SunToolkit cause AWT to be
initialized? I just wonder if this test will ru
On 23/10/2013 2:10 PM, David DeHaven wrote:
Updated webrev:
http://cr.openjdk.java.net/~ddehaven/8025673/jdk.2/
Summary of changes since last:
- Added awt_headless to java_props_t (set to NULL by default which does not set
the property)
Not sure about this part. We already force this proper
On 24/10/2013 1:11 AM, Artem Ananiev wrote:
On 10/23/2013 4:34 PM, Anthony Petrov wrote:
On 10/23/2013 08:52 AM, David Holmes wrote:
On 23/10/2013 2:10 PM, David DeHaven wrote:
Updated webrev:
http://cr.openjdk.java.net/~ddehaven/8025673/jdk.2/
Summary of changes since last:
- Added
David,
In src/share/native/java/lang/java_props.h the new field should really
also be in ifdef MACOSX.
The change to System.c allays my concerns there.
You can also consider the hotspot changes Reviewed.
Thanks,
David H.
On 24/10/2013 1:52 PM, David DeHaven wrote:
Another option (I think
On 4/02/2014 7:51 AM, Magnus Ihse Bursie wrote:
On 2014-02-03 21:44, Omair Majid wrote:
Whoops. Updated webrevs:
root: http://cr.openjdk.java.net/~omajid/webrevs/system-libpng/02/
jdk: http://cr.openjdk.java.net/~omajid/webrevs/system-libpng/02-jdk/
Due to this, I'd like to ask you to please
Hi Artem,
I would guess this is a deadlock with the process lock. But that first stack
trace is very suspicious as you can't jump into the JVM from the OS critical
section code (or shouldn't!). The attach-listener thread stack looks wrong
as well - again jumping to VM code from OS code.
No i
Total silence on build-dev. Perhaps someone on awt-dev knows what to
look for?
Please cc me as I'm not a member of awt-dev.
Thanks,
David
Original Message
Subject: Missing -L path for xawt
Date: Mon, 06 Dec 2010 20:34:12 +1000
From: David Holmes
Organization: O
ks,
David
--
best regards,
Anthony
On 12/7/2010 3:06 AM, David Holmes wrote:
Total silence on build-dev. Perhaps someone on awt-dev knows what to
look for?
Please cc me as I'm not a member of awt-dev.
Thanks,
David
Original Message
Subject: Missing -L path for xawt
Dat
Hi Artem,
Artem Ananiev said the following on 12/07/10 21:14:
On 12/7/2010 3:06 AM, David Holmes wrote:
Total silence on build-dev. Perhaps someone on awt-dev knows what to
look for?
Could you provide an exact build error you're observing, please?
As far as I know, we shouldn'
cific customizations (conditional on defining
JAVASE_EMBEDDED in the build variables)
- New AWT event polling algorithm with changed defaults for SE-Embedded
(SE behaviour remains the same)
Thanks,
David Holmes
Java SE VM Embedded Team
FYI - pushed via TL to keep all the SE-Embedded changes together.
David
Original Message
Subject: hg: jdk7/tl/jdk: 7030063: AWT support for SE-Embedded integration
Date: Fri, 25 Mar 2011 11:10:37 +
From: david.hol...@oracle.com
To: jdk7-chan...@openjdk.java.net, compiler-..
Very simple review - the mapfile was missing an entry for a new native
method added in 7030063 and caused an UnsatisfiedLinkError
http://cr.openjdk.java.net/~dholmes/jdk7-clone/webrev-7035109/
Failing test now passes.
Due to the urgency this will get pushed directly into the TL PIT jdk
repo s
/Canada Pacific
Subject: Re: Urgent Request for review: 7035109 Regression: awt
SplashScreen/test18.sh fails - missing mapfile entry
David Holmes wrote:
Very simple review - the mapfile was missing an entry for a new
native
method added in 7030063 and caused an UnsatisfiedLinkError
http://cr.o
Hi Alan,
Alan Bateman said the following on 04/20/11 01:46:
I'm currently looking at the location of our native libraries (the
context is jigsaw, not jdk7) and I'm wondering about xawt/libmawt.so and
headless/libmawt.so. Would I be correct to say that they aren't strictly
required to be a sub-
Alan Bateman said the following on 04/20/11 21:01:
David Holmes wrote:
libmawt.so is known to the VM. We use it with Embedded to detect if we
are currently running our headless JRE or not: if xawt/libmawt.so (or
motif21/libxawt.so) isn't present then it is an Embedded headless JRE.
S
Alan Bateman said the following on 04/20/11 23:10:
David Holmes wrote:
:
The only glitch I see with that is that the
GraphicsEnvironment.getHeadlessProperty code is Java code while to
check for the native lib we'd need native code.
The VM code is just stat'ing the library to che
Alan Bateman said the following on 04/20/11 21:55:
David Holmes wrote:
It's a different definition of "headless". The JDK can have headful
capabilities but operate in headless-mode - all the libs are still
present. The SE-Embedded headless JRE has had all the headful libs
s
This isn't a hotspot issue but an AWT (or rather java2d) issue. I've
cc'ed the AWT folk and bcc'd hotspot.
The incident report is mis-filed and I'll report that.
David Holmes
Yasumasa Suenaga said the following on 06/06/11 21:24:
> Hi,
>
> Our customer
ic links" error.
A full clean should fix it, but then you need to see what the original
error was caused by.
David Holmes
-
Message du 29/06/11 21:29
De : "Anthony Petrov"
A : goues...@orange.fr
Copie à : awt-dev@openjdk.java.net
Objet : Re: KDE Task bar
goues...@orange.fr said the following on 07/02/11 06:11:
libstdc++ devel package is installed but libstdc.so is not found. How can I
solve this problem?
Install the missing dev package for your distro.
David
Message du 01/07/11 14:34
De : "David Holmes"
A : goues...@orange.f
esn't reveal libstdc.so as being an real entity.
Now I think about it it should just be libc - no "std".
Does the linker error specifically say libstdc.so? Can you show the link
command that is being used.
David
Message du 01/07/11 23:24
De : "David Holmes"
A
Kapta Ulo said the following on 08/02/11 19:45:
The Java 7 release seems to have broken the LWJGL project on Linux, it no longer works
and complains that "libjawt.so" is not loaded. The project has been calling the
following method: java.awt.Toolkit.getDefaultToolkit(); to ensure that this nati
se()'d as it
may be that the way AppContext is used you can't actually get concurrent
modification of numAppContexts. But there's no way to discern that from the
AppContext code so it would be safer to use the AtomicInteger.
Cheers,
David Holmes
- Clemens
Hi Clemens,
On 19/08/2011 10:34 AM, Clemens Eisserer wrote:
Hi David,
Part of the missing picture here is how AppContexts get created and
dispose()'d as it may be that the way AppContext is used you can't
actually get concurrent modification of numAppContexts. But there's no
w
On 19/08/2011 6:40 PM, Clemens Eisserer wrote:
Found a mistake, corrected version at:
http://cr.openjdk.java.net/~ceisserer/7080700/webrev.02/
It ended up with numAppContexts=2 when class-initialization was done,
although there was only one context.
The original code is rather strange. The stat
On 20/08/2011 8:12 AM, Clemens Eisserer wrote:
The original code is rather strange. The static field will be default
initialized to zero, the AppContext constructor will increment it to 1,
then the static block explicitly sets it to one.
It would be cleaner/clearer if the field we
Hi Clemens,
On 21/08/2011 9:25 PM, Clemens Eisserer wrote:
On our caciocavallo-web demo server I sometimes experience endless spinning
in an EventDispatchThread (in run()) which should have been shut down long
ago by AppContext.dispose() - causing our server to consume 100% cpu.
I tried to anyl
On 22/08/2011 8:17 PM, Clemens Eisserer wrote:
Thanks again for taking a look at my comments and for your patience :)
Threads are my core interest :)
It seems to me that when the app context is being shutdown in this
manner that part of that should be to purge/clear the event queue.
On 25/08/2011 2:20 AM, Clemens Eisserer wrote:
Hi again,
Please find the latest version of the "full" patch at:
http://cr.openjdk.java.net/~ceisserer/7081670/webrev_full.02/
Because the return value of pumpOneEventForFilters(int id) redundant as it
always equals shutdown, I now just set shutdown
On 26/08/2011 2:39 AM, Clemens Eisserer wrote:
Hi David,
Thanks for your feedback.
You changed from Lock to ReentrantLock so that you could use
isHeldByCurrentThread(), but that locks in (pardon the pun) the kind of
Lock that AppContext must use.
You should add a comment explai
On 26/08/2011 8:58 AM, Clemens Eisserer wrote:
Hi,
Yes I understand why you added the check. I'm not sure what you mean
about hiding the InterruptedException though. As I understood the
scenario the interrupt() breaks the thread out of await() by throwing
IE, which is then caug
On 12/10/2011 5:23 PM, Charles Lee wrote:
On 10/12/2011 03:12 PM, David Holmes wrote:
On 12/10/2011 4:26 PM, Charles Lee wrote:
sys/unistd.h, sys/fcntl.h are not supported in AIX. And according to the
POSIX.1-2008 (http://pubs.opengroup.org/onlinepubs/9699919799/), I have
changed them to
Chris,
I just discovered that there is an additional change needed for
JAVASE_EMBEDDED. On the JDK side we also have a check to try and
determine if this is a headless or headful JRE, because a true
headless-JRE requires the special HToolkit. That code checks for the
existence of lib//xawt to
PS. I was also going to query about the continued existence of other
Motif related code - even libmawt is still referenced in the comments of
a couple of Motif specific functions. Is that now "dead" code?
David
On 11/11/2011 3:00 PM, David Holmes wrote:
Chris,
I just discovered
The AWT eventqueue thread has called System.exit and is waiting for a
shutdown hook thread to complete. I'm guessing that thread is Thread-0,
which is currently out in native code executing WToolkit.shutdown. So
from the Java stacks there is no way to tell what that thread is doing
(ie whether
This is a tweak to the cross-compilation rules in sun/xawt/Makefile to
force correct compilation of the sizers utility.
http://cr.openjdk.java.net/~dholmes/7171653/webrev/
webrev is against tl/jdk but I can use a different repo if you prefer.
Now that we use CFLAGS_32/64 in the cross compilati
I have a review from AWT (thanks Anthony), can I have one from build please.
Any preference as to where to push this?
Thanks,
David
On 25/05/2012 4:20 PM, David Holmes wrote:
This is a tweak to the cross-compilation rules in sun/xawt/Makefile to
force correct compilation of the sizers utility
On 11/07/2012 11:46 PM, Leonid Romanov wrote:
Hi,
Please review a fix for 7181027: [macosx] Unable to use headless mode. The problem here
is that for headless mode "java.awt.graphicsenv" system property should be
CGraphicsEnvironment because the way GraphicsEnvironment.createGE() method works:
Hi Oleg,
"deadlock" always grabs my attention :)
On 12/07/2012 2:08 AM, Oleg Pekhovskiy wrote:
Thank you for the review, Anthony,
please review the next version of fix:
http://cr.openjdk.java.net/~bagiras/7u6/7177040.2
I followed your suggestions there.
I also added 'volatile' for isFlushing
olved with OSX, and why OSX headless is handled differently to
Solaris/linux (which don't use HToolkit).
David
On 12.07.2012, at 5:15, David Holmes wrote:
On 11/07/2012 11:46 PM, Leonid Romanov wrote:
Hi,
Please review a fix for 7181027: [macosx] Unable to use headless mode. The proble
On 12/07/2012 10:18 PM, Anthony Petrov wrote:
On 07/12/12 05:41, David Holmes wrote:
It also seems that with this fix the interrupted EDT will not detach due
to the flush being in progress. The EDT will resume the pumpEvents loop
in its run() method. If the interrupt state of the EDT has
tests with your fix, btw?
--
best regards,
Anthony
On 07/12/12 12:58, Leonid Romanov wrote:
Perhaps Anthony might be able to answer your question: he has tinkered
a lot with headless related stuff.
David, are you implying that in the current form my fix is no-go?
On 12.07.2012, at 5:15, David
nks,
David
Thanks,
Oleg
7/13/2012 1:10 AM, David Holmes wrote:
On 12/07/2012 10:18 PM, Anthony Petrov wrote:
On 07/12/12 05:41, David Holmes wrote:
It also seems that with this fix the interrupted EDT will not detach
due
to the flush being in progress. The EDT will resume the pumpEvents
I'm just wary of it. I'm curious what would have been done if this
HToolkit class had not existed?
David
-
--
best regards,
Anthony
On 7/13/2012 1:26 AM, David Holmes wrote:
On 12/07/2012 10:33 PM, Anthony Petrov wrote:
The logic is all in src/solaris/native
On 14/07/2012 12:23 AM, Mike Swingler wrote:
On Jul 13, 2012, at 6:22 AM, Anthony Petrov wrote:
On 7/13/2012 5:09 PM, David Holmes wrote:
On 13/07/2012 10:58 PM, Anthony Petrov wrote:
I dug into the code history a little. The following Mike's changeset is
"to blame" for us
90 matches
Mail list logo
