Weijun Wang wrote:
Updated:
root: http://cr.openjdk.java.net/~weijun/7087428/control/webrev.00/
jdk: http://cr.openjdk.java.net/~weijun/7087428/webrev.01/
I also update Makefile to put jdk_sound to its correct alphabetical
position.
The changes look okay to me. The jdk_misc batch is still an
On 28/10/2011 11:39, Neil Richards wrote:
:
Hi Pavel,
I'm not sure I understand the problem here.
There have been several successful submissions previously committed
using exactly this form of copyright statement, eg:
http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/c0602036be5d
Konstantin,
Can you hold off pushing these tests until there has been wider review?
I may be mistaken but I think that many of these tests (at least for the
non-client areas) were deliberately not pushed to jdk7u and jdk8 when
bringing the port in. From what I can remember there was overlap
On 04/08/2013 18:04, Joe Darcy wrote:
Hello,
Please review this fix for
8022190: Fix varargs lint warnings in the JDK
http://cr.openjdk.java.net/~darcy/8022190.0/
Full patch below.
While the @SafeVarargs annotation generally suppresses compiler
warnings about methods, when the
On 01/11/2013 11:18, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk 8.
Most of tests in the sound area, and some tests in the client,
java.lang, security, jmx etc has incorrect copyright.
According to the http://openjdk.java.net/faq
GPL v2 + the Classpath exception for the class
On 24/01/2014 06:50, Joe Darcy wrote:
Hello,
As part of the JDK 9 warnings cleanup, for all the javax.swing classes
which stated
Serialized objects of this class will not be compatible with
future Swing releases. ...
I've added a @SuppressWarnings(serial) annotation if one was not
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 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 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 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 07/02/2014 07:53, Joe Darcy wrote:
Hello,
Please review the webrev to address
JDK-8033908: Fix serial lint warnings in com.sun.java.swing.plaf
http://cr.openjdk.java.net/~darcy/8033908.0/
This looks fine although for cases where you comment that the supertypes
aren't serial
On 13/02/2014 08:00, Joe Darcy wrote:
Hello,
Please review the largely tedious but straightforward fix for
JDK-8034169: Fix serial lint warnings in javax.swing
http://cr.openjdk.java.net/~darcy/8034169.0/
With the change, all of java.swing and it subclasses compile cleanly
with the
On 05/03/2014 20:30, Joe Darcy wrote:
Hello,
Please review this webrev which addresses serial warnings in
mac-specific code:
JDK-8035692 : Fix serial lint warnings in mac-specific code
http://cr.openjdk.java.net/~darcy/8035692.0/
This looks okay to me on the assumption that nothing
On 10/03/2014 06:55, Joe Darcy wrote:
Hello,
I've adjusted the patch based on changes to the client repo in the
interim:
http://cr.openjdk.java.net/~darcy/8033908.1/
Please review.
This looks okay to me. A minor inconsistency is tmp, tmp2, .. in one
file whereas it's tmp1, tmp2, .. in
On 07/06/2014 00:42, Joe Darcy wrote:
Hello,
One of the classes in the Apple laf code commits the classic mistake
of override equals without also overriding hashCode. Please review my
addition of a hashCode method:
diff -r 717cad3f30fe
On 25/08/2014 03:03, Wang Weijun wrote:
New webrevs updated
http://cr.openjdk.java.net/~weijun/8055723/core/webrev.00/
Includes modules java.base and security-related modules and the jarsigner
tool
http://cr.openjdk.java.net/~weijun/8055723/client/webrev.00
Includes the java.desktop
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 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 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 22/06/2015 16:44, Alexander Kulyakhtin wrote:
Hi,
Could you, please, review the test-only changes for the JDK-8076468
CR: JDK-8076468 Add @modules to the tests in jdk_desktop test group
Webrev: http://cr.openjdk.java.net/~akulyakh/8076468/webrev.05/
@modules keywords have been added to the
On 07/05/2018 10:26, Prasanta Sadhukhan wrote:
:
Modified webrev to use InteropProvider
http://cr.openjdk.java.net/~psadhukhan/fxswing.9/
This looks okay although for consistent then InteropImpl could be
renamed too.
-Alan
On 09/05/2018 15:42, Philip Race wrote:
:
Qn. to Mandy & Alan : it seems there is no need to mention this module
in make/common/Modules.gmk in order to get it built, but is there any
advantage in doing so ? I mean without it, there is no conscious
listing of
it as a module nor classification
On 08/05/2018 06:51, Prasanta Sadhukhan wrote:
Modified webrev to rename to InteropProviderImpl
http://cr.openjdk.java.net/~psadhukhan/fxswing.10/
This looks okay to me.
-Alan
On 05/05/2018 16:20, Prasanta Sadhukhan wrote:
Updated webrev to modify java.desktop module-info.java (only
difference between webrev7 and this) to remove the duplicate exports
of sun.awt so we will have now
exports sun.awt to
jdk.accessibility,
jdk.unsupported.desktop;
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 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 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, 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 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 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 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 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 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 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 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 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 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 Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov wrote:
> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
>
> This could be done more efficiently(up to x20
41 matches
Mail list logo
