On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote:
> The "java.util.logging.LogManager" class uses the "threadgroup sandboxing"
> via an AppContext to support "applet logging isolation". The AppContext class
> became useless since the plugin and webstart are no longer supported and
>
On Tue, 1 Jun 2021 15:21:33 GMT, Weijun Wang wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>>
On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>>
On Fri, 21 May 2021 18:00:13 GMT, Phil Race wrote:
> Are you suggesting that the patch doesn't need testing as it is ? It should
> be the same either way.
> It is very straight forward to run the automated tests across all platforms
> these days.
> I get the impression that no one is
On Thu, 20 May 2021 04:22:32 GMT, Phil Race wrote:
>> That is unfortunate, but nonetheless I think required to be done.
>> We have acknowledeged this can't reasonably be called an RFE, so the JEP is
>> introducing bugs/technical debt/call it what you will. This should generally
>> be part of a
On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote:
> Please review this implementation of [JEP
> 411](https://openjdk.java.net/jeps/411).
>
> The code change is divided into 3 commits. Please review them one by one.
>
> 1.
>
On Tue, 18 May 2021 12:42:08 GMT, Sean Mullan wrote:
>> src/java.base/share/classes/java/lang/SecurityManager.java line 315:
>>
>>> 313: *
>>> 314: * @since 1.0
>>> 315: * @deprecated The Security Manager is deprecated and subject to
>>> removal in a
>>
>> Javadoc will prefix, in bold,
On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote:
> Please review this implementation of [JEP
> 411](https://openjdk.java.net/jeps/411).
>
> The code change is divided into 3 commits. Please review them one by one.
>
> 1.
>
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
>
On Wed, 17 Mar 2021 16:44:19 GMT, Andy Herrick wrote:
> I cannot find any instances where the scope can be narrowed
Are you about AquaInternalFrameUI.mouseRelased, BasicPopupMenuUI. stateChanged,
and other non-trivial methods?
-
PR: https://git.openjdk.java.net/jdk/pull/2920
On Tue, 16 Mar 2021 17:49:42 GMT, Henry Jen wrote:
> > Using an anonymous class for the main class looks strange and hard to
> > believe anyone is relying on this. I wonder if we should do more checking
> > LauncherHelper.validateMainClass to reject cases like this.
>
> I raised that same
On Tue, 16 Mar 2021 07:43:54 GMT, Sergey Bylokhov wrote:
>> This bug is similar to https://bugs.openjdk.java.net/browse/JDK-8076264, and
>> the fix looks fine.
>
>> Maybe the AWT folk should decide what name should be displayed in this
>> case. The canonical name was chosen when all main
On Sat, 13 Mar 2021 00:43:33 GMT, Alexander Matveev
wrote:
>> implementation of
>> JDK-8256145: JEP 398: Deprecate the Applet API for Removal
>
> Marked as reviewed by almatvee (Committer).
Have you looked at narrowing the use of the SuppressWarnings to local variable
declarations to avoid
On Sun, 20 Dec 2020 17:05:21 GMT, Andrey Turbanov
wrote:
> 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo
jrtfs is compiled twice, the second is to --release 8 so it can be packaged
into jrt-fs.jar for use by IDEs/tools running on older JDK releases. So need to
be
On Thu, 19 Nov 2020 14:24:18 GMT, Alan Bateman wrote:
> This change terminally deprecates the following methods defined by
> java.lang.ThreadGroup
>
> - stop
> - destroy
> - isDestroyed
> - setDaemon
> - isDaemon
>
> The stop method has been deprecated sinc
On Fri, 20 Nov 2020 20:12:31 GMT, Stuart Marks wrote:
>> Marked as reviewed by mchung (Reviewer).
>
> I think the current deprecation wording is actually too specific regarding
> the raciness between TG destruction and created-but-not-started threads.
> That's just one of the flaws of thread
oup). These methods
> should be terminally deprecated so they can be degraded in a future release
> and eventually removed.
>
> CSR with more information: https://bugs.openjdk.java.net/browse/JDK-8256644
Alan Bateman has updated the pull request with a new target base due to a merge
or a
On Fri, 20 Nov 2020 16:05:24 GMT, Sean Mullan wrote:
> If you agree, I can file an issue.
Yes, make sense to separate this out, esp. permission targets such as
"stopThread" where all usages are in deprecated methods. However, I don't
expect "modifyThreadGroup" would be deprecated, at least
On Fri, 20 Nov 2020 15:27:14 GMT, Roger Riggs wrote:
>> Alan Bateman has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains four addi
oup). These methods
> should be terminally deprecated so they can be degraded in a future release
> and eventually removed.
>
> CSR with more information: https://bugs.openjdk.java.net/browse/JDK-8256644
Alan Bateman has updated the pull request with a new target base due to a merge
or a
On Fri, 20 Nov 2020 14:03:20 GMT, Sean Mullan wrote:
> I think it would be useful in the javadoc of the RuntimePermission targets
> (stopThread, etc) to add a note/link that the corresponding method that the
> permission applies to is terminally deprecated. Something as simple as "Note
> that
On Fri, 20 Nov 2020 14:05:09 GMT, Sean Mullan wrote:
>> This change terminally deprecates the following methods defined by
>> java.lang.ThreadGroup
>>
>> - stop
>> - destroy
>> - isDestroyed
>> - setDaemon
>> - isDaemon
>>
>> The stop method has been deprecated since=1.2 because it is
This change terminally deprecates the following methods defined by
java.lang.ThreadGroup
- stop
- destroy
- isDestroyed
- setDaemon
- isDaemon
The stop method has been deprecated since=1.2 because it is inherently unsafe.
It is time to terminally deprecate this method so it can be
On Thu, 12 Nov 2020 20:48:13 GMT, Andy Herrick wrote:
>> JDK-8189198: Add "forRemoval = true" to Applet APIs
>
> Andy Herrick has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes the unrelated changes
> brought in by the
On Thu, 10 Sep 2020 13:53:10 GMT, David Holmes wrote:
>> @dholmes-ora raises a good point. Hopefully there is a balance point between
>> a dozen different bugs / pull requests
>> each targeting one area and one bug / PR targeting a dozen separate areas. I
>> don't have a good general rule to
On Thu, 10 Sep 2020 08:47:35 GMT, Dmitriy Dumanskiy
wrote:
>> Before this Enhancement can be formally reviewed, you will need a JBS bug
>> ID. If you are already working with a
>> Committer or Reviewer in the `jdk` project who has agreed to sponsor your
>> change, they can file the
On 23/03/2020 19:03, Magnus Ihse Bursie wrote:
The build tools (small java tools that are run during the build to
generate source code, or data, needed in the JDK) have historically
been placed in the "make" directory. This maybe made sense long time
ago, but does not do so anymore.
On 24/06/2019 15:23, Langer, Christoph wrote:
:
The original issues didn't have CSRs attached but it really feels CSRish. Let
me know whether I shall create CSRs as you're still sorting out the process.
The sun.applet package was JDK internal so no CSR required to change or
remove anything in
On 15/09/2018 22:00, Philip Race wrote:
It was exported in the past .. and it was publicly documented ..
http://www.oracle.com/technetwork/articles/javase/appletwarning-135102.html
.. so I think Sergey was correct in his "JDK" scope.
Implementation would be for something entirely internal.
I
On 31/08/2018 19:42, Igor Ignatyev wrote:
Alan, Chris,
thanks for looking at it, I went w/ the alternative suggested by
Chris. that required a sprinkle of doPrivileged in the testlibrary,
but now Sockets/policy.* files grant the minimal required permissions
to the test code.
the
On 28/08/2018 17:50, Igor Ignatyev wrote:
http://cr.openjdk.java.net/~iignatyev//8210039/webrev.00/index.html
698 lines changed: 114 ins; 240 del; 344 mod
Hi all,
could you please review this clean up of jdk testlibrary?
the patch updates the tests to use jdk.test.lib.Platform instead of
On 23/03/2018 15:15, Magnus Ihse Bursie wrote:
:
Very much so, yes. I've found a lot of dubious exports, everything from global
variables (yuck!) to functions that does not seem to be used anymore, to lots
of strange exports.
The changes looks good to me and I think we should follow this up
On 03/04/2017 14:58, Sergey Bylokhov wrote:
"Return null if java.awt.Image is not visible, the java.desktop
module is not loaded, or the java.desktop module is not in the
run-time image."
This is better.
Sergey - the “not readable” part is no longer applicable as
reflective access to
On 31/03/2017 17:36, Sergey Bylokhov wrote:
Hello,
Please review the fix for jdk9.
There is an optional dependency of java.datatransfer module from java.desktop.
If the java.desktop module is not present then the application will not be able
to use java.awt.Image and related
On 14/03/2017 19:58, Mandy Chung wrote:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8174977/webrev.00/index.html
Small edits to the license files, contributed by jeannette.h...@oracle.com. I
am sponsoring it. Also I have reviewed it.
Mandy
Looks okay to me.
On 06/10/2016 17:28, Phil Race wrote:
OK .. so long as there's no --add-modules needed for that.
Seems to work. Updated webrev :-
http://cr.openjdk.java.net/~prr/8167126.1/
No --add-modules. The updated webrev looks okay to me.
-Alan
On 06/10/2016 16:58, Phil Race wrote:
Similar modules were on the BOOT list.
Can you explain what each of these lists are and the implications
of being (and not being) listed on each of them ?
-phil.
The BOOT_MODULES list is the list of modules defined to the boot loader,
the PLATFORM_MODULES
On 05/10/2016 23:01, Phil Race wrote:
Webrev : http://cr.openjdk.java.net/~prr/8167126/
The upcoming jigsaw changes to limit use of setAccessible [1] mean
that some work-arounds for non-SE API users will be broken.
To provide for continued access to the capability (albeit via a
different
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 product no longer need to be there for
JDK 9. Many of them have already been
On 10/01/2016 09:19, Chris Hegarty wrote:
In preparation for JEP 260, and as per the suggestion over on the core libs[1],
sun.misc.PerformanceLogger should be moved to sun.util.logging.
http://cr.openjdk.java.net/~chegar/8146735/
This looks okay to me.
-Alan
On 10/12/2015 11:09, Yuri Nesterenko wrote:
Hi colleagues,
please review this test-only fix for AWT tests in 9-jigsaw repository.
CR is
https://bugs.openjdk.java.net/browse/JDK-8135008
Webrev:
http://cr.openjdk.java.net/~yan/8135008/webrev.00/
Here, after November updates in jtreg, 14
On 25/06/2015 00:42, joe darcy wrote:
:
diff -r db09207cc779 test/TEST.ROOT
--- a/test/TEST.ROOTWed Jun 24 15:15:10 2015 -0700
+++ b/test/TEST.ROOTWed Jun 24 16:33:09 2015 -0700
@@ -8,8 +8,11 @@
# would not count as randomness by this definition.) Extra care
# should be taken to
On 24/06/2015 12:08, Pavel Rappo wrote:
Hi everyone,
Could you please review my change for JDK-8064925?
http://cr.openjdk.java.net/~prappo/8064925/webrev.01/
The main goal is to see if the proposed spec change and the overall approach are
correct.
The update to the API docs looks good to
On 17/06/2015 18:47, Sergey Bylokhov wrote:
On 27.05.15 19:03, Sergey Bylokhov wrote:
Hi, Alan.
On 27.05.15 18:51, Alan Bateman wrote:
A minor comment on the usage of ByteArrayOutputStream is that you
should be able to replace this soon with:
Image image = toolkit.createImage
On 27/05/2015 14:48, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk9.
The usage of getResource() was changed to getResourceAsStream(). Note
that before the fix the toolkit.getImage() cached the image, but it
should not be a problem in the new code, because cursor itself is
cached
On 02/04/2015 16:15, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk 9.
There are a number of public methods in the java.awt.Toolkit class,
which reference the unsupported java.awt.dnd.peer and java.awt.peer
interfaces.
There is a decision to remove these references as
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.
http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.00/
Mandy cc'ed me with your review comments I skimmed through the webrev
On 16/03/2015 18:30, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk 9.
There are a number of public API which reference the unsupported
java.awt. dnd.peer interfaces.
protected
java.awt.dnd.DragSource.createDragSourceContext(java.awt.dnd.peer.DragSourceContextPeer,
...)
public
On 05/03/2015 12:51, Sergey Bylokhov wrote:
The new version of the fix:
http://cr.openjdk.java.net/~serb/8074028/webrev.06
Font.getPeer() was renamed to Font.getFontPeer().
This part looks good to me. I assume someone working in this area will
give the rest of the changes a thorough review.
On 04/03/2015 15:03, Magnus Ihse Bursie wrote:
I believe all warnings are important to check! Unfortunately, this has
not been done for a lot of warnings for a lot of time. :(
Right, although in the past we had some areas close to be cleared of
warnings, it's just that we didn't keep up the
On 04/03/2015 12:37, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk 9.
There are a number of public API whichreference the unsupported
java.awt.peer interfaces.
public java.awt.Component.getPeer() @deprecated 1.1
public java.awt.Font.getPeer() @deprecated 1.1
public
On 04/03/2015 13:17, Magnus Ihse Bursie wrote:
:
I intend to file individual bugs to handle these remaining warnings,
so the net result will be a completely warning free build.
I also intend to file individual bugs on all the libraries that has
had warnings disabled. I expect the outcome of
On 19/02/2015 16:30, Roman Kennke wrote:
:
Hmm. I am not totally familiar, but from what I heard at FOSDEM from
Mark Reinhold, it is possible to export certain APIs *only to other
known modules*. This is similar in concept to C++ friends, except it
happens on a module basis instead of class
On 16/02/2015 11:57, Sergey Bylokhov wrote:
Hello,
Here is an updated version of the fix:
http://cr.openjdk.java.net/~serb/8039269/webrev.01
The updated webrev looks good (indentation inconsistent in places but
that isn't important here).
-Alan.
On 13/02/2015 18:01, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk 9.
As requested cursor related properties/images were moved from /lib to the
java.desktop.
- Image prefixes were removed because I moved them to the os specific
location.
- Windows version of
On 13/01/2015 15:45, Sergey Bylokhov wrote:
On 13.01.2015 17:23, Alan Bateman wrote:
Typo in my mail, I meant verify-modules.
They are currently issues with verify-modules and boot cycle builds
so I think verify-modules is currently disabled (at least in
jdk9/dev). Erik is working
On 13/01/2015 14:17, Sergey Bylokhov wrote:
On 13.01.2015 17:05, Alan Bateman wrote:
On 13/01/2015 13:52, Sergey Bylokhov wrote:
Yes it is unnecessary. The new versions:
http://cr.openjdk.java.net/~serb/8056298/webrev.03/jdk
http://cr.openjdk.java.net/~serb/8056298/webrev.03/root
This looks
On 13/01/2015 13:52, Sergey Bylokhov wrote:
Yes it is unnecessary. The new versions:
http://cr.openjdk.java.net/~serb/8056298/webrev.03/jdk
http://cr.openjdk.java.net/~serb/8056298/webrev.03/root
This looks good to (and I assume that make verify-images passes).
-Alan.
On 13/01/2015 11:40, Sergey Bylokhov wrote:
:
The new versions:
http://cr.openjdk.java.net/~serb/8056298/webrev.02/jdk
http://cr.openjdk.java.net/~serb/8056298/webrev.02/root
Bug: https://bugs.openjdk.java.net/browse/JDK-8056298
Thanks for the update. The only thing that isn't clear to me is
On 12/01/2015 20:29, Sergey Bylokhov wrote:
Hello.
Please review a fix for jdk 9.
In the fix a sun.datatransfer and a java.awt.datatransfer packages
were moved to the separate module java.datatransfer.
But sun.awt.datatransfer still located in java.desktop. I tested full
jdk(all modules
On 16/12/2014 06:07, joe darcy wrote:
Hello,
Please review the next step of suppressing the deprecation warnings
the client libraries, this time in windows-specific desktop code:
JDK-8067092: Suppress windows-specific deprecation warnings in the
java.desktop module
On 16/12/2014 18:29, Phil Race wrote:
Yes .. no technical constraint there.
Although I was pondering going further and seeing if we can actually
remove
the public method java.awt.peer.Peer Component.getPeer()
since with the module system the peer package is not accessible and this
is then even
On 12/12/2014 20:46, Phil Race wrote:
:
2) Some significant fraction of all the warnings are for getPeer() :-
dev/jdk/src/java.desktop/share/classes/java/awt/Container.java:821:
warning: [deprecation] getPeer() in Component has been deprecated
The issue here is that the deprecation javadoc
On 10/12/2014 00:41, joe darcy wrote:
Hello,
In support of JEP 212: Resolve Lint and Doclint Warnings
(http://openjdk.java.net/jeps/212), which is targeted to JDK 9, please
review the large but straightforward set of changes in the webrev:
http://cr.openjdk.java.net/~darcy/8066621.0/
On 19/09/2014 17:22, Phil Race wrote:
Gosh that's going to be a pain to maintain .. here's an update to the
334 affected lines in that file ! Look ok ?
http://cr.openjdk.java.net/~prr/8056216.1
-phil
Ideally there should be just one line per directory, it should only list
individual files
On 28/08/2014 20:36, Phil Race wrote:
* All of the awt-related directories (libawt_* and common) include an
unnecessary extra layer, the sun directory. It is not needed anymore,
Let's *not* do that. It also affects the destination package.
Remember sun.* is the protected top-level package ..
On 27/08/2014 11:57, Anthony Petrov wrote:
Hi Magnus,
Those look like reasonable suggestions. Could you please file separate
bugs for each of these issues? Also, please note that most of them
belong to 2D, not AWT (e.g. the font-, color-, d3d-, and
opengl-related files) even though they're
On 22/07/2014 15:04, Petr Pchelko wrote:
Hello,
I've updated the fix. The new version is located here:
http://cr.openjdk.java.net/~pchelko/9/8037485/webrev.01/
http://cr.openjdk.java.net/%7Epchelko/9/8037485/webrev.01/
I've reverted RMI changes as they will be handled separately.
Also I've
On 17/07/2014 12:07, Petr Pchelko wrote:
Hello,
Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8037485
The fix is available at:
http://cr.openjdk.java.net/~pchelko/9/8037485/webrev.00
http://cr.openjdk.java.net/%7Epchelko/9/8037485/webrev.00
This fix separates
On 01/07/2014 09:35, Petr Pchelko wrote:
Hello,
The changes in the public API have been approved, so let me continue
the review process.
For your convenience:
The bug: https://bugs.openjdk.java.net/browse/JDK-8047336
The fix: http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.00/
On 02/07/2014 12:10, Petr Pchelko wrote:
Hello, Anthony, Alan.
Thank you for the review, the new version is located here:
http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.01/
http://cr.openjdk.java.net/%7Epchelko/9/8047336/webrev.00/
I've changed the code to throw an InternalError if we
On 19/05/2014 07:53, Paul Sandoz wrote:
If i don't have permission to push to the client repo (which might be likely) i
will need to hand over the patch to yourself or Sergey to commit. And i presume
this will have to be a separate issue.
If you do decide to split this then it will require
On 14/05/2014 09:15, Paul Sandoz wrote:
:
And here what could have been a 2 line change is 25 ..
http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/src/share/classes/sun/font/StandardTextSource.java.sdiff.html
So I would say leave the variable names alone
On 12/05/2014 11:55, Paul Sandoz wrote:
On May 12, 2014, at 12:42 PM, Alan Bateman alan.bate...@oracle.com wrote:
On 12/05/2014 11:03, Paul Sandoz wrote:
It covers many areas and i have grouped the patches into such areas to aid
reviewing. When commenting please including core-libs
On 12/05/2014 11:03, Paul Sandoz wrote:
It covers many areas and i have grouped the patches into such areas to
aid reviewing. When commenting please including core-libs.
The groupings are a bit odd but I looked through the -core, -io,
-management and -rmi patches and don't see any issues.
On 21/03/2014 15:22, Sergey Bylokhov wrote:
On 3/21/14 7:10 PM, roger riggs wrote:
The macro would just as useful (if I understand the cases) without
the cast.
How useful is a simple definition as:
#define IS_TRUE(obj) ((obj) ? JNI_TRUE : JNI_FALSE)
then it would look ok to see these in
cc'ing awt-dev as this where the Applet code is maintained.
In any case, the suppressing of serial warnings looks okay to me,
assuming of course they don't leak into the serialized stream of a
supported type.
-Alan.
On 12/03/2014 06:18, Joe Darcy wrote:
Hello,
Please review the patch
On 24/02/2014 09:02, Petr Pchelko wrote:
Hello,
Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8035640
The fix is available at:
http://cr.openjdk.java.net/~pchelko/9/8035640/webrev.00/
In AWT code we have quite a lot of C++ sources, but JNU_CHECK_EXCEPTION macros
On 21/02/2014 11:43, Anthony Petrov wrote:
Hi Andrew,
Client code is basically anything in 2D, AWT, i18n, beans, a11y,
ImageIO, Sound, or Swing. I.e., anything related to GUI/desktop.
In this particular case Omair is changing the SplashScreen code which
belongs to AWT, hence the choice of
On 12/02/2014 12:59, michael cui wrote:
On 02/10/2014 05:36 PM, Alan Bateman wrote:
A minor comment on test/java/net/URLPermission/nstest/lookup.sh is
that the resulting line length is 182 characters and this will likely
be annoying for future side-by-side views. So I think I'd split
On 10/02/2014 07:00, michael cui wrote:
:
Please review the newest version at :
http://cr.openjdk.java.net/~tyan/michael/JDK-8028711/webrev.03/
This looks good to me.
There are a couple of places where javac wasn't updated. A few that I
noticed are:
On 31/01/2014 23:46, Joseph Darcy wrote:
:
Discussions are on going as to which forest client libraries fixes
should go into, the client forest (where closed-source deployment
changes happen to be going) or to the dev forest where all the other
libraries work is going; FWIW, I favor the
On 31/01/2014 18:35, Joe Darcy wrote:
*ping*
Thanks,
-Joe
I've skimmed through the changes and don't see anything obviously wrong.
All the @returns are okay. For the @param then it requires a bit of
domain knowledge (and I don't know this area). For
On 31/01/2014 18:36, Joe Darcy wrote:
*ping*
Thanks,
-Joe
This update looks okay to me. It would be good for someone working in
this area to re-visit these at some point to see if any of these are
actually serialized (indirectly) and whether any other actions should be
taken.
-Alan
On 31/01/2014 09:08, Sergey Bylokhov wrote:
On 26.01.2014 13:30, Alan Bateman wrote:
As a side point, client changes have been going into jdk9/client
rather than jdk9/dev so I just wonder if there might be changes
backed up in jdk9/client that might cause issues when merged.
It will be really
On 26/01/2014 09:30, Alan Bateman wrote:
The only non-client changes that I see are to Setup.gmk (previously
reviewed on build-dev) and Sdp.java.
I see the others now, just hard to spot in a large mind-numbing patch :-)
All looks good but as I look at this again then I see a few Iterator
On 27/01/2014 19:52, Joe Darcy wrote:
:
Alan, I strongly prefer to limit this patch to just cast cleanup.
I understand, I was just pointing it out that some of these could use
for-each and that would also eliminate the cast.
:
Based on the results of an exploratory jprt job, listed below
On 25/01/2014 19:10, Joe Darcy wrote:
Hello,
Please review my large, but largely straightforward, changes to fix
JDK-8032733: Fix cast lint warnings in client libraries
http://cr.openjdk.java.net/~darcy/8032733.0/
Many of the changes were enabled by the clone method of an array being
On 02/01/2014 17:22, Volker Simonis wrote:
Hi,
could somebody please review the following small change:
http://cr.openjdk.java.net/~simonis/webrevs/8031134/
It's the straight forward implementation of the basic printing
infrastructure on AIX and shouldn't have any impact on the existing
On 10/12/2013 18:37, Mandy Chung wrote:
Alan,
The change looks good. A minor one - in the class description of
java.lang.SecurityManager, I suggest to remove the references to
java.awt.AWTPermission line 143 and 214.
Thanks Mandy. I left in these links as it's just a sample list of
On 11/12/2013 13:17, Artem Ananiev wrote:
Hi, Alan,
the changes look fine to me.
A short quick question: what is the reason to introduce a new
AWTPermissions class as a holder for various AWTPermission constants?
We can have the same fields directly in AWTPermission. The only
difference is
On 11/12/2013 16:16, Sean Mullan wrote:
The code changes and suggested wording for the updated methods look
fine to me. Please add a release-note=yes label to the issue. The
permissions security guide will also need to be updated with the new
behavior of these methods:
In JDK 8 we deprecated the JDK 1.1-era SecurityManager methods
checkTopLevelWindow, checkSystemClipboard and
checkAccessAwtEventQueueAccess with a warning that they would be changed
in a future release to check AllPermission. At the same time we changed
the java.awt.Window and Toolkit
On 10/12/2013 19:20, Phil Race wrote:
was trusted to bring up a top-level winodw. It no longer has a use
What's a winodw ? :-)
Thanks, I'll fix that.
It no longer has a use suggests it does nothing so might be better
phrased as
no longer the recommended or sole way to perform this check
On 21/11/2013 15:54, Volker Simonis wrote:
:
But actually I've just realized that it is not need at all, because
'aix_close.c' isn't in the PATH for any other OS than AIX (that could
be probably called a feature of the new file layout:) So I'll simply
change it to:
48 ifeq
On 05/11/2013 16:28, Sergey Bylokhov wrote:
Hello,
Updated version:
http://cr.openjdk.java.net/~serb/8027696/webrev.01/
Dates and spaces were fixed.
Thanks Sergey, I sampled a few and they look correct.
The only thing is that I'm not sure about is test/Makefile, it's just
not clear whether
On 03/09/2013 10:56, Artem Ananiev wrote:
Hi, Alan,
the spec changes (still) look fine. I would move the new test from
test/java/awt/etc to test/java/awt/security, as we have a few closed
tests in that folder, which will eventually be opened.
Thanks for taking care of this.
Thanks Artem,
This is a follow-up to thread from June [1] where I proposed deprecating
the SecurityManager checkTopLevelWindow, checkSystemClipboardAccess,
checkTopLevelWindow methods.
At the time then Anthony agreed with the spec change but I didn't come
back with a final webrev and get the change
On 01/04/2013 23:16, Dan Xu wrote:
Hi All,
In this fix, I have updated files in JDK libraries to use @Native
annotation instead of @GenerateNativeHeader to mark classes that
contain no native methods but constants used by native codes.
@GenerateNativeHeader was added earlier in the
On 19/03/2013 12:19, Laurent Bourgès wrote:
Dear all,
I run recently netbeans profiler on my swing application (Aspro2:
http://www.jmmc.fr/aspro) under linux x64 platform and figured out a
performance and waste issue related to PlatformLogger.
Actually, the JavaLogger implementation uses a
1 - 100 of 112 matches
Mail list logo
