Re: RFR: 8284780: Need methods to create pre-sized HashSet and LinkedHashSet [v19]
On Wed, 8 Jun 2022 17:49:38 GMT, XenoAmess wrote: >> as title. > > XenoAmess has updated the pull request incrementally with one additional > commit since the last revision: > > clean up Calendar Running tests and awaiting review from security team. Our internal test system is backlogged and tests might not complete in time to get into JDK 19. - PR: https://git.openjdk.java.net/jdk/pull/8302
Re: RFR: 8284780: Need methods to create pre-sized HashSet and LinkedHashSet [v17]
On Fri, 27 May 2022 18:40:32 GMT, XenoAmess wrote: >> as title. > > XenoAmess has updated the pull request incrementally with one additional > commit since the last revision: > > do it as naotoj said Reviewers for i18n, net, nio, and security, please review call site changes in your areas. Thanks. - PR: https://git.openjdk.java.net/jdk/pull/8302
Re: RFR: 8186958: Need method to create pre-sized HashMap [v22]
On Thu, 14 Apr 2022 21:27:16 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with one additional > commit since the last revision: > > java.xml.crypto's usage downgrade grammar to 1.8 I've also written a release note for this change. Please review. https://bugs.openjdk.java.net/browse/JDK-8284975 - PR: https://git.openjdk.java.net/jdk/pull/7928
Re: RFR: 8186958: Need method to create pre-sized HashMap [v22]
On Thu, 14 Apr 2022 21:27:16 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with one additional > commit since the last revision: > > java.xml.crypto's usage downgrade grammar to 1.8 Marked as reviewed by smarks (Reviewer). OK, go ahead and integrate! - PR: https://git.openjdk.java.net/jdk/pull/7928
Re: RFR: 8186958: Need method to create pre-sized HashMap [v21]
On Thu, 14 Apr 2022 20:16:38 GMT, Sean Mullan wrote: >>> Are the changes necessary for this part? >> >> @seanjmullan no, they are just performance refinement. >> >> If you really that wanna 100% sync , >> >> I can use the old 1.8 api to migrate that part, and make a mirror pr to that >> part of https://github.com/apache/santuario-xml-security-java >> >> Is this solution acceptable then? > >> > Are the changes necessary for this part? >> >> @seanjmullan no, they are just performance refinement. >> >> If you really that wanna 100% sync , >> >> I can use the old 1.8 api to migrate that part, and make a mirror pr to that >> part of https://github.com/apache/santuario-xml-security-java >> >> Is this solution acceptable then? > > Yes, that would be preferred. Thanks! I'd like to see a confirmation from @seanjmullan to make sure the issues with Santuario are resolved satisfactorily. Other than that I think it's pretty well covered. I've already run these changes through our internal test system and they look fine. I'll do a final recheck and let you know. - PR: https://git.openjdk.java.net/jdk/pull/7928
Re: RFR: 8186958: Need method to create pre-sized HashMap [v21]
On Thu, 14 Apr 2022 19:53:45 GMT, Bradford Wetmore wrote: >> XenoAmess has updated the pull request incrementally with one additional >> commit since the last revision: >> >> add `@LastModified: Apr 2022` to DocumentCache > > I learned something new about HashMap today... > > I looked at java.security.cert and sun.security.* and that part LGTM. > > That said, you need to check with @seanjmullan for the java.xml.crypto code. > We try to keep the code in sync with the Apache code. As this is a new API, > we probably can't push this kind of change to Apache as they need to support > older releases. Thanks @bradfordwetmore and @seanjmullan for looking at this, and @XenoAmess for following up quickly. To summarize, it sounds like the only issues are with the changes to two files in the `java.xml.crypto` area, as those need to be maintained in sync with Apache Santuario. Right? In both cases it looks like the HashMap is likely being under-allocated, so the fix would be to inline to capacity computation, something like `new HashMap<>((int) Math.ceil(length / 0.75))` I guess. - PR: https://git.openjdk.java.net/jdk/pull/7928
Re: RFR: 8186958: Need method to create pre-sized HashMap [v16]
On Wed, 13 Apr 2022 20:06:34 GMT, Naoto Sato wrote: >> XenoAmess has updated the pull request incrementally with one additional >> commit since the last revision: >> >> revert changes in: >> src/java.desktop >> src/java.management >> src/jdk.internal.vm.ci >> src/jdk.jfr >> src/jdk.management.jfr >> src/jdk.management >> src/utils/IdealGraphVisualizer > > Looks good for changes in i18n related call sites, assuming that the > copyright years will be updated. > > Should we need some additions/modifications to the hashmap optimal capacity > utility `test/lib/jdk/test/lib/util/OptimalCapacity.java`? @naotoj wrote: > Should we need some additions/modifications to the hashmap optimal capacity > utility `test/lib/jdk/test/lib/util/OptimalCapacity.java`? The only thing that uses this utility now is `test/jdk/java/lang/Enum/ConstantDirectoryOptimalCapacity.java`, which is on the problem list. The cleanup is covered by [JDK-8282120](https://bugs.openjdk.java.net/browse/JDK-8282120). After this PR gets integrated, the Enum ConstantDirectory will be initialized with `HashMap.newHashMap(universe.length)` so the OptimalCapacity test won't really be testing anything. I'll take another look at it and the library utility, but I suspect the cleanup may simply be removing them entirely. - PR: https://git.openjdk.java.net/jdk/pull/7928
Re: RFR: 8186958: Need method to create pre-sized HashMap [v18]
On Wed, 13 Apr 2022 22:20:14 GMT, XenoAmess wrote:
>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> update LastModified
src/java.base/unix/classes/java/lang/ProcessEnvironment.java line 102:
> 100: /* Only for use by Runtime.exec(...String[]envp...) */
> 101: static Map emptyEnvironment(int capacity) {
> 102: return new StringEnvironment(HashMap.newHashMap(capacity));
This change is correct, since this is called with the length of an array that's
used to populate the environment. It really should be named `size` instead of
`capacity`. However the windows version of this code simply calls
`super(capacity)` as it's a subclass of `HashMap`, which is wrong. Well,
probably not worth changing this now. We may need to revisit this later to do
some cleaning up. (And also the strange computation in the static initializer
at line 71.)
-
PR: https://git.openjdk.java.net/jdk/pull/7928
Re: RFR: 8186958: Need method to create pre-sized HashMap [v18]
On Wed, 13 Apr 2022 22:20:14 GMT, XenoAmess wrote:
>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> update LastModified
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java
line 1819:
> 1817: Map items;
> 1818: LargeContainer(int size) {
> 1819: items = HashMap.newHashMap(size*2+1);
I'm wondering if we should change this to just `newHashMap(size)` since it
looks like this container is intended to hold up to `size` items. @JoeWang-Java
? I suspect the `size*2+1` was a failed attempt at allocating a HashMap of the
correct capacity for `size` mappings.
-
PR: https://git.openjdk.java.net/jdk/pull/7928
Re: RFR: 8186958: Need method to create pre-sized HashMap [v18]
On Wed, 13 Apr 2022 22:20:14 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with one additional > commit since the last revision: > > update LastModified src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DocumentCache.java line 171: > 169: _current = 0; > 170: _size = size; > 171: _references = HashMap.newHashMap(_size); Not `_size+2` ? - PR: https://git.openjdk.java.net/jdk/pull/7928
Re: RFR: 8186958: Need method to create pre-sized HashMap [v18]
On Wed, 13 Apr 2022 22:20:14 GMT, XenoAmess wrote:
>> 8186958: Need method to create pre-sized HashMap
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> update LastModified
src/java.base/share/classes/java/lang/Character.java line 8574:
> 8572: private static final HashMap
> aliases;
> 8573: static {
> 8574: aliases = HashMap.newHashMap(162);
@naotoj Seems like this magic number is likely to go out of date. Should there
be a test for it like the one you updated for NUM_ENTITIES?
[JDK-8283465](https://bugs.openjdk.java.net/browse/JDK-8283465).
-
PR: https://git.openjdk.java.net/jdk/pull/7928
Re: RFR: 8186958: Need method to create pre-sized HashMap [v16]
On Wed, 13 Apr 2022 16:29:11 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with one additional > commit since the last revision: > > revert changes in: > src/java.desktop > src/java.management > src/jdk.internal.vm.ci > src/jdk.jfr > src/jdk.management.jfr > src/jdk.management > src/utils/IdealGraphVisualizer Reviewers for i18n, net, nio, and security, please review call site changes in your areas. Thanks. - PR: https://git.openjdk.java.net/jdk/pull/7928
Re: RFR: JDK-8276447 Deprecate finalization-related methods for removal [v3]
On Wed, 1 Dec 2021 19:23:59 GMT, Brent Christian wrote:
>> Here are the code changes for the "Deprecate finalizers in the standard Java
>> API" portion of JEP 421 ("Deprecate Finalization for Removal") for code
>> review.
>>
>> This change makes the indicated deprecations, and updates the API spec for
>> JEP 421. It also updates the relevant @SuppressWarning annotations.
>>
>> The CSR has been approved.
>> An automated test build+test run passes cleanly (FWIW :D ).
>
> Brent Christian has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains 33 commits:
>
> - Merge branch 'master' into 8276447
> - Merge branch 'master' into 8276447
> - merge
> - @SuppressWarnings(removal) in Windows CKey.java
> - Add jls tag to runFinalization methods
> - Update wording of Object.finalize, new paragraph is now bold
> - update Object.finalize javadoc
> - update Object.finalize JavaDoc and @deprecated tag
> - Update Object.finalize deprecation message
> - Indicate that runFinalizers does nothing if finalization is disabled or
> removed
> - ... and 23 more:
> https://git.openjdk.java.net/jdk/compare/0dfb3a70...8cde0674
Marked as reviewed by smarks (Reviewer).
src/jdk.jconsole/share/classes/sun/tools/jconsole/SummaryTab.java line 116:
> 114: StringBuilder buf;
> 115:
> 116: @SuppressWarnings("deprecation")
Item for future cleanup: refactor the call to
`getObjectPendingFinalizationCount()` at line 219 (!) into a local variable
declaration, and then move the warnings suppression to that declaration. This
reduces the scope of warnings suppression.
-
PR: https://git.openjdk.java.net/jdk/pull/6465
Re: RFR: 8250564: Remove terminally deprecated constructor in GSSUtil
On Tue, 5 Jan 2021 21:02:21 GMT, Joe Darcy wrote: > Back in JDK 16, two unintended default constructors were identified and > deprecated for removal. The time has come to remove them. > > Please also review the corresponding CSRs: > > JDK-8258521 Remove terminally deprecated constructor in GSSUtil > https://bugs.openjdk.java.net/browse/JDK-8258521 > > JDK-8258522 Remove terminally deprecated constructor in java.net.URLDecoder > https://bugs.openjdk.java.net/browse/JDK-8258522 > > Calling a static method using an instance of a class, as done in the test > B6463990.java, is a coding anti-pattern that generates a lint warning; that > warning in enabled in the JDK build. > > Thanks, Marked as reviewed by smarks (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1948
Re: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base
On Sun, 4 Oct 2020 11:55:50 GMT, Andrey Turbanov wrote: >> 8258422: Cleanup unnecessary null comparison before instanceof check in >> java.base > > I believe this changes is useful and still actual: > 1. improve code to make it easier to read. > 2. performance should be improved a bit too I’ll see if I can get somebody to take a look at this. - PR: https://git.openjdk.java.net/jdk/pull/20
Re: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase
On Fri, 11 Sep 2020 15:17:58 GMT, Bradford Wetmore wrote: >> Ok, sorry for the distraction. > > Our local Santuario maintainer says: > > In general, changes to Apache Santuario should also be made at Apache so we > stay in sync. Hi @doom369, I hope we didn't end up wasting too much of your time with this. I wanted to respond to a comment you made earlier in this PR, > I have in mind dozens of improvements all over the code like this one. It's hard to see, but as you discovered, the JDK has different groups of people maintaining different areas, and sometimes there are hidden constraints on those different areas, for example, to avoid divergence with upstream source bases. And as you discovered, sometimes those source bases might need to maintain compatibility with an older JDK ... so we don't want to update this code even though it's IN the JDK. Those kind of constraints generally don't apply to code in the java.base module, since there's nothing upstream of it, and by definition it cannot depend on anything outside the JDK. Generally -- though there are exceptions -- we're more receptive to keeping stuff in java.base (and sometimes related modules close to the core) on the latest and greatest stuff. There are some constraints, however. There are some things we can't use too early during initialization of the JDK, such as lambdas. Also, there is some code lurking around that is sometimes executed by the boot JDK, which is typically one release behind. (This is definitely the case for tools like javac, but I think it might also apply to some things in base.) Anyway, if you'd like to pursue some of these improvements, drop a note to core-libs-dev@openjdk and we can talk about it. Thanks. - PR: https://git.openjdk.java.net/jdk/pull/29
Re: RFR: 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler
On 5/23/19 6:39 AM, Langer, Christoph wrote: big thanks for your great updates here. This all looks a lot cleaner: http://cr.openjdk.java.net/~clanger/webrevs/8223553.3/ Great, glad to help. While I'm still unsure about the underlying reasons for this disagreement between the compilers, that might take a while to resolve. Putting in these fixes isn't very intrusive and it seems to make people's lives easier, so I don't have any objection to them going in. In the other 3 locations, we're able to eliminate the EC4J issues by introducing a local variable with the right type declaration. Sounds like a viable workaround. At Eclipse we have the following bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=530236. It refers to the OpenJDK bug https://bugs.openjdk.java.net/browse/JDK-8016207. I'm wondering whether this should be submitted and I should at the same time submit another bug to evaluate these code places at a time when the final resolution for JDK-8016207 was provided? Overall, introducing a local variable is more-or-less reasonable even if it's used only once. One point is that somebody might come along and "clean up" the code and inline local variables and reintroduce the problem. Another point is that, hypothetically, if in the future Eclipse is changed to match javac's behavior, these changes should be reverted. The bug database is a good place to capture actions that need to take place in the future. Unfortunately, it's pretty far from these locations, so the existence of such a bug wouldn't prevent the accidental cleanup from happening. That would indicate having a comment in the code at these locations. On the other hand, if Eclipse is "fixed" and these locations don't get cleaned up for a long time, it doesn't seem like that big a deal. I'd suggest to put a comment at these 3 locations, something like: // local variable required here; see JDK-8223553 and not bother with filing another bug report to track this. I'll defer to Martin as to how he wants to handle the ConcurrentSkipListMap.java change. s'marks
Re: RFR: 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler
Hi Christoph,
I'm still not entirely sure why this is so, but the introduction of a local
variable in MethodHandles.java seems to make things work for Eclipse. Addition
of a local variable seems to be minimally invasive, so it makes sense to see if
this technique can be applied to other cases.
(In ConcurrentSkipListMap the issue seems to be solved by addition of wildcards,
as I had suggested previously, and it cleans up the unchecked cast that was
there in the first place. So I think that one is ok already.)
In ManagementFactory.java, an unchecked cast and warnings suppression is
introduced, and in ExchangeImpl.java a helper method was introduced. I've found
ways to introduce local variables that make Eclipse happy for these cases.
(Well, on localized test cases; I haven't built the whole JDK with Eclipse.) See
diffs below.
The type of the local variable in ExchangeImpl.java is a mouthful. Interestingly
I had to change Function.identity() to the lambda x -> x. I think this is
because Function.identity() returns a function that doesn't allow its return
type to vary from its argument, whereas x -> x allows a widening conversion.
(This might provide a clue as to the differences between javac and Eclipse here,
but a full understanding eludes me.)
s'marks
diff -r 006dadb903ab
src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
---
a/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
Mon May 13 17:15:56 2019 -0700
+++
b/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
Fri May 17 15:46:14 2019 -0700
@@ -1712,9 +1712,7 @@
Map m = (Map) o;
try {
Comparator cmp = comparator;
-@SuppressWarnings("unchecked")
-Iterator> it =
-(Iterator>)m.entrySet().iterator();
+Iterator> it = m.entrySet().iterator();
if (m instanceof SortedMap &&
((SortedMap)m).comparator() == cmp) {
Node b, n;
diff -r 006dadb903ab
src/java.management/share/classes/java/lang/management/ManagementFactory.java
---
a/src/java.management/share/classes/java/lang/management/ManagementFactory.java
Mon May 13 17:15:56 2019 -0700
+++
b/src/java.management/share/classes/java/lang/management/ManagementFactory.java
Fri May 17 15:46:14 2019 -0700
@@ -872,12 +872,12 @@
public static Set>
getPlatformManagementInterfaces()
{
-return platformComponents()
+Stream> pmos =
platformComponents()
.stream()
.flatMap(pc -> pc.mbeanInterfaces().stream())
.filter(clazz ->
PlatformManagedObject.class.isAssignableFrom(clazz))
-.map(clazz -> clazz.asSubclass(PlatformManagedObject.class))
-.collect(Collectors.toSet());
+.map(clazz -> clazz.asSubclass(PlatformManagedObject.class));
+ return pmos.collect(Collectors.toSet());
}
private static final String NOTIF_EMITTER =
diff -r 006dadb903ab
src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java
--- a/src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java
Mon May 13 17:15:56 2019 -0700
+++ b/src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java
Fri May 17 15:46:14 2019 -0700
@@ -92,8 +92,9 @@
CompletableFuture c2f =
c2.getConnectionFor(request, exchange);
if (debug.on())
debug.log("get: Trying to get HTTP/2 connection");
-return c2f.handle((h2c, t) -> createExchangeImpl(h2c, t, exchange,
connection))
-.thenCompose(Function.identity());
+CompletableFuture>>
fxi =
+c2f.handle((h2c, t) -> createExchangeImpl(h2c, t, exchange,
connection));
+return fxi.thenCompose(x -> x);
}
}
Re: RFR: 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler
On 5/14/19 9:16 PM, Martin Buchholz wrote:
src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
Regarding the change in this particular file, I'd suggest the following:
diff -r 006dadb903ab -r 92e1fdce45e0
src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
---
a/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
Mon May 13 17:15:56 2019 -0700
+++
b/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
Thu May 16 15:04:30 2019 -0700
@@ -1712,9 +1712,7 @@
Map m = (Map) o;
try {
Comparator cmp = comparator;
-@SuppressWarnings("unchecked")
-Iterator> it =
-(Iterator>)m.entrySet().iterator();
+Iterator> it = m.entrySet().iterator();
if (m instanceof SortedMap &&
((SortedMap)m).comparator() == cmp) {
Node b, n;
I have no idea if it will be accepted by the Eclipse IDE, but this seems like a
cleaner change to me than introducing a raw type.
***
Christoph,
On the general issue of compilation differences between javac and the Eclipse
IDE, have you raised a bug with them?
s'marks
Re: 4523159: suggestion for a bugfix for 13 year old "jars in path with !"
Hi Daniel, Thanks for looking at this old bug. I'm concerned about the approach of looking in the filesystem to determine how to parse the URL. If that's the case, then it's no longer possible to look at just the URL string and determine what it represents. Instead, it's possible that different systems will parse the URL differently depending upon the contents of their filesystems, or that the same system will parse the same URL differently at different times if the contents of its filesystem has changed. That leads toward another, different class of errors. There is clearly a bug here, which is that the '!' character is ambiguous: either it's the separator between the jar filename and the path to the entry within the jar file, or it's part of the jar filename. The solution suggested in the bug report by Michael McMahon (cc'd) is to allow for a quoting or escape mechanism to disambiguate the meaning of the '!' character. Would it be possible to pursue that solution? s'marks On 9/15/15 5:27 AM, Daniel Wilhlem wrote: Hi, Our download manager http://jdownloader.org/ has millions of customers. Some of them also suffered from the 13 year old bug http://bugs.java.com/view_bug.do?bug_id=4523159. The issue happens because '!/' is used as seperator between a jar file and its content in URLStreamHandler and JarURLConnection. I hereby want to suggest our bugfix. It consists of a modified sun.net.www.protocol.jar.Handler and sun.net.www.protocol.jar.JarURLConnection. Instead of searching for '!/' and using the first hit, our customized sun.net.www.protocol.jar.Handler loops through URL.getFile() via indexof and substring and tests if it specifies the actual jar file on disk. In case the path contains '!/' we return a customized sun.net.www.protocol.jar.JarURLConnection that overrides getJarFileURL(),getJarEntry(),getEntryName() to provide the correct information. The one disadvantage of this bugfix is the additional IO introduced by File.exits(), but that can be considered//neglectable/./ Please find attached our customized classes. Best Regards Daniel Wilhelm PS: sean.cof...@oracle.com/sean.cof...@oracle.com told me to post this to net-dev -- --- Daniel Wilhelm CTO, Co-Founder Appwork GmbH T: +49 (911)97923112 (Mo-Fr 9:00 - 17:00 CET) Schwabacherstraße 117, 90763 Fürth, Germany
hg: jdk8/tl/jdk: 8027536: rmic: add deprecation warning message when generating JRMP static stubs/skeletons
Changeset: 6c343d3d2721 Author:smarks Date: 2013-12-13 18:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6c343d3d2721 8027536: rmic: add deprecation warning message when generating JRMP static stubs/skeletons Reviewed-by: mchung, dmocek ! src/share/classes/sun/rmi/rmic/Main.java ! src/share/classes/sun/rmi/rmic/resources/rmic.properties
hg: jdk8/tl/jdk: 7190106: java/rmi/reliability/benchmark fails intermittently because of use of fixed port
Changeset: df819e356901 Author:tyan Date: 2013-12-03 14:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/df819e356901 7190106: java/rmi/reliability/benchmark fails intermittently because of use of fixed port Reviewed-by: smarks, mduigou ! test/ProblemList.txt ! test/java/rmi/reliability/benchmark/bench/rmi/Main.java ! test/java/rmi/reliability/benchmark/bench/serial/Main.java - test/java/rmi/reliability/benchmark/runRmiBench.sh - test/java/rmi/reliability/benchmark/runSerialBench.sh
hg: jdk8/tl/jdk: 8028757: CharSequence.subSequence improperly requires a new CharSequence be returned
Changeset: accd6ffd4b3f Author:smarks Date: 2013-12-03 15:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/accd6ffd4b3f 8028757: CharSequence.subSequence improperly requires a new CharSequence be returned Reviewed-by: alanb, darcy, mduigou ! src/share/classes/java/lang/CharSequence.java ! src/share/classes/java/lang/String.java
hg: jdk8/tl/jdk: 8029489: StringJoiner spec for setEmptyValue() and length() is malformatted
Changeset: c6b6b515cf4f Author:smarks Date: 2013-12-03 18:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c6b6b515cf4f 8029489: StringJoiner spec for setEmptyValue() and length() is malformatted Reviewed-by: darcy, lancea, mduigou ! src/share/classes/java/util/StringJoiner.java
hg: jdk8/tl/jdk: 7174936: several String methods claim to always create new String
Changeset: 4bc37b6c4133 Author:smarks Date: 2013-11-21 16:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4bc37b6c4133 7174936: several String methods claim to always create new String Reviewed-by: dholmes, bchristi, alanb, lancea ! src/share/classes/java/lang/String.java
hg: jdk8/tl/jdk: 8028638: java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java fails
Changeset: 19d2e9649138 Author:smarks Date: 2013-11-19 15:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/19d2e9649138 8028638: java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java fails Reviewed-by: lancea ! test/java/rmi/testlibrary/RMID.java
hg: jdk8/tl/jdk: 8023863: deprecate support for statically-generated stubs from RMI (JRMP); ...
Changeset: 1ea1b24c1a04 Author:smarks Date: 2013-10-30 18:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1ea1b24c1a04 8023863: deprecate support for statically-generated stubs from RMI (JRMP) 4449028: exportObject() javadoc should specify behavior for null socket factories Reviewed-by: dfuchs, darcy ! src/share/classes/java/rmi/server/RemoteStub.java ! src/share/classes/java/rmi/server/UnicastRemoteObject.java ! src/share/classes/java/rmi/server/package.html
hg: jdk8/tl/jdk: 5063500: Formatter spec says char is not an integral type; ...
Changeset: 8ea272253285 Author:smarks Date: 2013-10-25 14:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8ea272253285 5063500: Formatter spec says char is not an integral type 7126305: Wrong Unicode value specified for format conversion character 'd' 8027287: incorrect example in Formatter javadoc Reviewed-by: rriggs, darcy, lancea ! src/share/classes/java/util/Formatter.java
hg: jdk8/tl/jdk: 8026427: deprecate obsolete APIs from java.rmi
Changeset: 9fbf35589211 Author:smarks Date: 2013-10-22 14:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9fbf35589211 8026427: deprecate obsolete APIs from java.rmi Reviewed-by: alanb, dfuchs ! src/share/classes/java/rmi/RMISecurityManager.java ! src/share/classes/java/rmi/activation/ActivationGroup.java ! src/share/classes/java/rmi/server/ServerRef.java ! src/share/classes/java/rmi/server/SocketSecurityException.java
hg: jdk8/tl/jdk: 8023447: change specification to allow RMI activation to be optional
Changeset: 6731ea9123f2 Author:smarks Date: 2013-09-09 14:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6731ea9123f2 8023447: change specification to allow RMI activation to be optional Reviewed-by: darcy, alanb, olagneau ! src/share/classes/java/rmi/activation/Activatable.java ! src/share/classes/java/rmi/activation/ActivationDesc.java ! src/share/classes/java/rmi/activation/ActivationGroup.java ! src/share/classes/java/rmi/activation/ActivationGroupID.java ! src/share/classes/java/rmi/activation/ActivationID.java ! src/share/classes/java/rmi/activation/package.html
hg: jdk8/tl/jdk: 8022445: fix RMISocketFactory example to avoid using localhost
Changeset: 7496ec8bab76 Author:smarks Date: 2013-08-22 15:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7496ec8bab76 8022445: fix RMISocketFactory example to avoid using localhost Reviewed-by: chegar, alanb ! src/share/classes/java/rmi/server/RMISocketFactory.java
hg: jdk8/tl/jdk: 8022479: clean up warnings from sun.tools.asm
Changeset: 8c50c27418d3 Author:smarks Date: 2013-08-07 16:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8c50c27418d3 8022479: clean up warnings from sun.tools.asm Reviewed-by: lancea, darcy ! src/share/classes/sun/tools/asm/Assembler.java ! src/share/classes/sun/tools/asm/ConstantPool.java ! src/share/classes/sun/tools/asm/Instruction.java ! src/share/classes/sun/tools/asm/SwitchData.java ! src/share/classes/sun/tools/asm/TryData.java
hg: jdk8/tl/jdk: 8022412: Fixed warnings in java.util root, except for HashMap
Changeset: 12c1b78acf9a Author:lagergren Date: 2013-08-06 12:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/12c1b78acf9a 8022412: Fixed warnings in java.util root, except for HashMap Reviewed-by: mduigou, darcy Contributed-by: marcus.lagerg...@oracle.com ! src/share/classes/java/util/ArrayPrefixHelpers.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/Comparator.java ! src/share/classes/java/util/Comparators.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/IdentityHashMap.java ! src/share/classes/java/util/Vector.java ! src/share/classes/java/util/WeakHashMap.java
hg: jdk8/tl/jdk: 8022440: suppress deprecation warnings in sun.rmi
Changeset: 31e923842d49 Author:smarks Date: 2013-08-06 14:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/31e923842d49 8022440: suppress deprecation warnings in sun.rmi Reviewed-by: mduigou ! src/share/classes/sun/rmi/runtime/Log.java ! src/share/classes/sun/rmi/server/ActivatableRef.java ! src/share/classes/sun/rmi/server/Dispatcher.java ! src/share/classes/sun/rmi/server/LoaderHandler.java ! src/share/classes/sun/rmi/server/UnicastRef.java ! src/share/classes/sun/rmi/server/UnicastServerRef.java ! src/share/classes/sun/rmi/server/Util.java ! src/share/classes/sun/rmi/transport/DGCImpl.java ! src/share/classes/sun/rmi/transport/StreamRemoteCall.java ! src/share/classes/sun/rmi/transport/Transport.java ! src/share/classes/sun/rmi/transport/proxy/RMIMasterSocketFactory.java ! src/share/classes/sun/rmi/transport/tcp/ConnectionMultiplexer.java ! src/share/classes/sun/rmi/transport/tcp/TCPTransport.java
hg: jdk8/tl/jdk: 8020854: change RMI javadocs to specify that remote objects are exported to the wildcard address
Changeset: 31759750ff63 Author:smarks Date: 2013-08-05 19:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/31759750ff63 8020854: change RMI javadocs to specify that remote objects are exported to the wildcard address Reviewed-by: rgallard, alanb ! src/share/classes/java/rmi/server/RMISocketFactory.java ! src/share/classes/java/rmi/server/UnicastRemoteObject.java
Re: Remaining doclint issues in java.net
On 8/2/13 2:37 AM, Chris Hegarty wrote: On 01/08/2013 22:18, Stuart Marks wrote: SocketAddress overloads. Two of them were within methods that declared throws Exception. The third was within a try/catch block that catches IOException. None of the three cases would suffer a source incompatibility. I cannot comment on the code you are talking about, but removing 'throws SE' from these constructors will affect anyone that is catching IOE ( since SE is a subclass of IOE ). Simple test: [...] You're correct, of course, that constructing a new DatagramPacket within a try/catch of IOException would suffer the source incompatibility. I had neglected to mention, though, that the try/catch(IOException) code that I looked at also did a bunch of other IOException-throwing stuff within the try block. So in that particular case the code wouldn't have had a compatibility issue. This isn't definitive, of course, but it does seem to supply some evidence that making this change would result in a relatively minor source incompatibility. Given the above, I still agree with the sentiment here. I will file a bug and proceed with the necessary changes to remove SE. Great! Glad to hear it. Thanks. s'marks
Re: Remaining doclint issues in java.net
On 7/31/13 2:39 PM, Matthew Hall wrote: On Wed, Jul 31, 2013 at 02:38:26PM -0700, Stuart Marks wrote: The alternative is to add @throws SocketException never to the javadoc, just to get rid of the doclint warning, but this has the consequence of requiring people to keep dead code around indefinitely, and furthermore it requires them to add new dead code every time they create a DatagramPacket. I have never understood in many years using Java why the compiler generates errors about attempting to catch supposedly-impossible exceptions, instead of warnings. For me it only leads to difficulties when I'm trying to write prototypes or refactor and clean up some old brittle code, and I run into that rather dubious sort of error. This is a good example of where it causes more harm than good. Is there still a really good reason for this over-paranoid compiler error given that checked exceptions aren't as popular as they used to be anyways? I don't have the definitive answer, but it was a very early Java design decision to make unreachable code be a compilation error instead of a warning. This is a matter of judgment, of course; reasonable people come down on different sides of this, for different cases. For example, see this Stackoverflow conversation: http://stackoverflow.com/questions/3795585/why-does-java-have-an-unreachable-statement-compiler-error * * * Meanwhile, I did a little bit of studying about DatagramPacket. The doclint warnings occur on two of the six DatagramPacket constructors: DatagramPacket(byte[] buf, int len, SocketAddress sa) DatagramPacket(byte[] buf, int off, int len, SocketAddress sa) There are two other equivalent overloaded constructors that take InetAddress and port arguments: DatagramPacket(byte[] buf, int len, InetAddress ia, int port) DatagramPacket(byte[] buf, int off, int len, InetAddress ia, int port) To my eye the InetAddress/port constructors are used quite a bit more often than the SocketAddress ones. I did a web search for java DatagramPacket example and looked at all the examples on the first page of hits. All of them used the InetAddress+port constructor overloads (including the Oracle Java tutorial). I didn't see any uses of the SocketAddress overloads. I also did an ohloh search for new DatagramPacket(: http://code.ohloh.net/search?s=%22new%20DatagramPacket%28%22p=2pp=0fl=Javamp=1ml=1me=1md=1ff=1filterChecked=true (HT: Dalibor) I looked through around 100 examples, and the vast majority of them use the InetAddress+port overloads. I saw three examples that use the SocketAddress overloads. Two of them were within methods that declared throws Exception. The third was within a try/catch block that catches IOException. None of the three cases would suffer a source incompatibility. This isn't definitive, of course, but it does seem to supply some evidence that making this change would result in a relatively minor source incompatibility. s'marks
Re: Remaining doclint issues in java.net
On 7/29/13 7:28 AM, Chris Hegarty wrote: There are two remaining doclint warnings in the java.net package. :javac -Xdoclint:all/protected src/share/classes/java/net/DatagramPacket.java src/share/classes/java/net/DatagramPacket.java:142: warning: no @throws for java.net.SocketException public DatagramPacket(byte buf[], int offset, int length, ^ src/share/classes/java/net/DatagramPacket.java:178: warning: no @throws for java.net.SocketException public DatagramPacket(byte buf[], int length, ^ These are caused by no @throws SE declaration on the constructors. As it happens 'throws SE' was incorrectly added to these constructors when introduced in 1.4. The original API specified that SE was thrown when the given SocketAddress was not supported. That was later changed to throw IAE, in 1.4.2. These constructor now can never throw SE. Removing 'throws SE' from the method declaration is a binary compatible change, but not source compatible ( XXX is never thrown in body of corresponding try statement ). I don't think breaking source compatibility for this kind of change is justified. If it is, then the solution is to simply remove 'throws SE'. Back in the real world, I guess we need to come up with some wording for the '@throws SE' declaration. Something vague like If an I/O Exception occurs, or can we put something stronger like will never be thrown ?? I'd like to make a case for removing 'throws SE' even though it's a source incompatible change. It's not that source incompatibilities are strictly prohibited. They are allowed, and it depends on how often they occur and how difficult they are to fix. I seem to recall there was a similar issue when more precise rethrow was added in Java 7; this was indeed a source incompatibility but a survey was done and it was quite rare. How often are these DatagramPacket constructors used? I'd have to say, probably more often than the fairly obscure cases that the more precise rethrow feature caused issues with. On the other hand, fixing up code that constructs a DatagramPacket ought to be pretty simple: removing the catch of SocketException. This is already known to be dead code, so it can simply be removed. The alternative is to add @throws SocketException never to the javadoc, just to get rid of the doclint warning, but this has the consequence of requiring people to keep dead code around indefinitely, and furthermore it requires them to add new dead code every time they create a DatagramPacket. I'm not claiming that removing 'throws SE' is obviously the right answer, but I'd like to see it considered seriously. s'marks
hg: jdk8/tl/jdk: 8020977: StringJoiner merges with itself not as expected
Changeset: 09a77a1bdbc3 Author:henryjen Date: 2013-07-30 15:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/09a77a1bdbc3 8020977: StringJoiner merges with itself not as expected Reviewed-by: psandoz, chegar, mduigou, smarks ! src/share/classes/java/util/StringJoiner.java ! test/java/util/StringJoiner/MergeTest.java
hg: jdk8/tl/jdk: 8019224: add exception chaining to RMI CGIHandler
Changeset: 6729f7ef94cd Author:smarks Date: 2013-06-27 13:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6729f7ef94cd 8019224: add exception chaining to RMI CGIHandler Reviewed-by: darcy ! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java
Re: RFR: 8019341: Update CookieHttpsClientTest to use the newer framework.
On 6/27/13 4:58 PM, Brad Wetmore wrote: Chris (and Michael), As my part of the intermittently failing test cleanup, I'm looking into a test of yours that has been intermittently failing. It's bug: https://jbs.oracle.com/bugs/browse/JDK-8017333 The open URL to view this bug is: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017333 which is failing the regression test you added for: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8a143213c65 You used a really old version of the test framework (pre-2003!) which doesn't output both the client and server exceptions. I've updated the test to use the new framework, and would like to put this back as a temporary measure so we can see what is really happening from any possible swallowed exceptions. Xuelei/I are stumped as to what might be happening, so hopefully this action will give some clarity. 8019341: Update CookieHttpsClientTest to use the newer framework. http://cr.openjdk.java.net/~wetmore/8019341/webrev.00/ Improving the exception handling seems mostly reasonable. It looks like startServer() and startClient() now both try to catch any exceptions and store them in variables for later processing. But they still are declared to throw Exception, and the code that calls them from the constructor throws away any exception that's caught there. Hm, it's hard to know what exception might be caught at that point, but since we don't really know what's going on, we probably shouldn't rule anything out. Most places catch Exception. One possibility to consider is whether an Error of some type might be thrown, which isn't caught by catch (Exception) clauses. In the place where you potentially have two exceptions to report, you might consider using the suppressed exception mechanism. This is bending the semantics a bit, but if the client is subordinate to the server (or vice versa) and both throw exceptions, only one can be propagated, so it could seem somewhat proper to consider one exception to have suppressed the other. It would be easiest to compare your test to the test/sun/security/ssl/templates/SSLSocketTemplate.java. They should be the same except for your test-specific code. Hm, a template-based framework? Might be worth investigating turning this into a library at some point. Brad P.S. I think AlanB/JoeD/StuartM will appreciate this effort. ;) Yes, indeed. :-) s'marks
hg: jdk8/tl/jdk: 8005646: TEST_BUG: java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup leaves process running
Changeset: c18f28312c49 Author:smarks Date: 2013-01-22 18:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c18f28312c49 8005646: TEST_BUG: java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup leaves process running Reviewed-by: mchung ! test/java/rmi/activation/ActivationSystem/unregisterGroup/ActivateMe.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/CallbackInterface.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/Callback_Stub.java ! test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup_Stub.java ! test/java/rmi/activation/ActivationSystem/unregisterGroup/rmid.security.policy
hg: jdk8/tl/jdk: 8006534: CLONE - TestLibrary.getUnusedRandomPort() fails intermittently-doesn't retry enough times
Changeset: 79fed1733d4a Author:jgish Date: 2013-01-17 15:09 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/79fed1733d4a 8006534: CLONE - TestLibrary.getUnusedRandomPort() fails intermittently-doesn't retry enough times Summary: Increase number of retries to twice the number of ports in the reserved range Reviewed-by: mduigou ! test/java/rmi/testlibrary/TestLibrary.java
hg: jdk8/tl/jdk: 8005582: java/lang/Runtime/exec/WinCommand.java intermittent test failures
Changeset: 13ff1089e625 Author:jgish Date: 2013-01-10 15:09 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/13ff1089e625 8005582: java/lang/Runtime/exec/WinCommand.java intermittent test failures Summary: Remove file-deletion code at cleanup which conflicts with jtreg cleanup Reviewed-by: chegar ! test/java/lang/Runtime/exec/WinCommand.java
hg: jdk8/tl/jdk: 7187882: TEST_BUG: java/rmi/activation/checkusage/CheckUsage.java fails intermittently
Changeset: 797e8a3dcd51 Author:smarks Date: 2013-01-07 18:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/797e8a3dcd51 7187882: TEST_BUG: java/rmi/activation/checkusage/CheckUsage.java fails intermittently Summary: Tighten up JavaVM test library API, and adjust tests to match. Reviewed-by: mchung, dmocek ! test/ProblemList.txt ! test/java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java ! test/java/rmi/activation/checkusage/CheckUsage.java ! test/java/rmi/registry/altSecurityManager/AltSecurityManager.java ! test/java/rmi/registry/checkusage/CheckUsage.java ! test/java/rmi/registry/reexport/Reexport.java ! test/java/rmi/testlibrary/JavaVM.java ! test/java/rmi/testlibrary/RMID.java ! test/java/rmi/transport/checkFQDN/CheckFQDN.java ! test/java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java ! test/sun/rmi/runtime/Log/4504153/Test4504153.java ! test/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java ! test/sun/rmi/transport/tcp/DeadCachedConnection.java
hg: jdk8/tl/jdk: 8005683: ProblemList.txt updates (01/2013)
Changeset: 92c3b24a8e9a Author:smarks Date: 2013-01-04 16:10 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92c3b24a8e9a 8005683: ProblemList.txt updates (01/2013) Reviewed-by: mchung, alanb Contributed-by: amy...@oracle.com ! test/ProblemList.txt
hg: jdk8/tl/jdk: 2 new changesets
Changeset: 0cfcba56cfa7 Author:jgish Date: 2012-12-28 18:32 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0cfcba56cfa7 8005594: Fix to 8003265 breaks build Summary: backout changeset 4472a641b4dc Reviewed-by: smarks, wetmore ! src/share/classes/com/sun/jndi/dns/DnsContext.java ! src/share/classes/com/sun/jndi/ldap/BasicControl.java Changeset: ac5e29b62288 Author:smarks Date: 2012-12-28 17:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac5e29b62288 Merge
hg: jdk8/tl/jdk: 8005290: remove -showversion from RMI test library subprocess mechanism
Changeset: 60adb69bf043 Author:smarks Date: 2012-12-20 20:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60adb69bf043 8005290: remove -showversion from RMI test library subprocess mechanism Reviewed-by: jgish, chegar, dmocek ! test/java/rmi/testlibrary/JavaVM.java ! test/java/rmi/testlibrary/StreamPipe.java ! test/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java
hg: jdk8/tl/jdk: 8004651: TEST: java/util/logging/CheckLockLocationTest.java failed to delete file (win)
Changeset: 56fd5479a98f Author:jgish Date: 2012-12-12 15:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/56fd5479a98f 8004651: TEST: java/util/logging/CheckLockLocationTest.java failed to delete file (win) Summary: Failure to delete test log file should be a warning instead of test failure Reviewed-by: mduigou, smarks ! test/java/util/logging/CheckLockLocationTest.java
hg: jdk8/tl/jdk: 8004317: TestLibrary.getUnusedRandomPort() fails intermittently, but exception not reported
Changeset: a971516029ab Author:jgish Date: 2012-12-05 21:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a971516029ab 8004317: TestLibrary.getUnusedRandomPort() fails intermittently, but exception not reported Reviewed-by: alanb, dmocek, smarks ! test/java/rmi/testlibrary/TestLibrary.java
hg: jdk8/tl: 8004131: move jdi tests out of core testset
Changeset: ab1ab9b148dd Author:smarks Date: 2012-11-28 17:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ab1ab9b148dd 8004131: move jdi tests out of core testset Reviewed-by: alanb, chegar ! make/jprt.properties
hg: jdk8/tl/jdk: 8004131: move jdi tests out of core testset
Changeset: 83d9f30ebeed Author:smarks Date: 2012-11-28 17:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/83d9f30ebeed 8004131: move jdi tests out of core testset Reviewed-by: alanb, chegar ! make/jprt.properties
hg: jdk8/tl/jdk: 8004134: More ProblemList.txt updates (11/2012)
Changeset: 7ccf93c60c4d Author:smarks Date: 2012-11-29 14:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7ccf93c60c4d 8004134: More ProblemList.txt updates (11/2012) Reviewed-by: alanb Contributed-by: amy...@oracle.com ! test/ProblemList.txt
hg: jdk8/tl/jdk: 7193406: Clean-up JDK Build Warnings in java.util, java.io
Changeset: 1f7c783e4f13 Author:dxu Date: 2012-08-31 13:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1f7c783e4f13 7193406: Clean-up JDK Build Warnings in java.util, java.io Summary: Clean-up JDK Build Warnings in java.util, java.io Packages Reviewed-by: smarks, darcy, khazra, dholmes, forax, dl, andrew, aph, omajid, ulfzibis, christos, mduigou ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/java/net/SocketPermission.java ! src/share/classes/java/nio/channels/AsynchronousFileChannel.java ! src/share/classes/java/nio/channels/FileChannel.java ! src/share/classes/java/util/ArrayDeque.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/ComparableTimSort.java ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/JumboEnumSet.java ! src/share/classes/java/util/PriorityQueue.java ! src/share/classes/java/util/PropertyPermission.java ! src/share/classes/java/util/PropertyResourceBundle.java ! src/share/classes/java/util/jar/JarVerifier.java ! src/share/classes/java/util/jar/Pack200.java ! src/share/classes/sun/util/PreHashedMap.java
hg: jdk8/tl/jdk: 7195099: update problem list with RMI test failures
Changeset: f9b11772c4b2 Author:smarks Date: 2012-08-30 18:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f9b11772c4b2 7195099: update problem list with RMI test failures Reviewed-by: alanb ! test/ProblemList.txt
hg: jdk8/tl/jdk: 7187876: ClassCastException in TCPTransport.executeAcceptLoop
Changeset: 8a82e5f9c47f Author:dmocek Date: 2012-08-02 18:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a82e5f9c47f 7187876: ClassCastException in TCPTransport.executeAcceptLoop Reviewed-by: dholmes, smarks ! src/share/classes/sun/rmi/transport/tcp/TCPTransport.java
hg: jdk8/tl/jdk: 7186111: fix bugs in java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup
Changeset: 018e555a7a07 Author:dmocek Date: 2012-07-27 16:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/018e555a7a07 7186111: fix bugs in java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup Reviewed-by: smarks, jgish ! test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup.java ! test/java/rmi/activation/ActivationSystem/unregisterGroup/group.security.policy ! test/java/rmi/activation/ActivationSystem/unregisterGroup/rmid.security.policy ! test/java/rmi/activation/ActivationSystem/unregisterGroup/security.policy
hg: jdk8/tl/jdk: 7184943: fix failing test com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java; ...
Changeset: 89129c0737f1 Author:dmocek Date: 2012-07-18 10:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/89129c0737f1 7184943: fix failing test com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java 7184946: fix failing test com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java Reviewed-by: smarks ! test/com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java ! test/com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java
hg: jdk8/tl/jdk: 6948101: java/rmi/transport/pinLastArguments/PinLastArguments.java failing intermittently
Changeset: 97eb7a4b1fdd Author:smarks Date: 2012-07-05 15:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/97eb7a4b1fdd 6948101: java/rmi/transport/pinLastArguments/PinLastArguments.java failing intermittently Reviewed-by: dholmes, smarks Contributed-by: Eric Wang yiming.w...@oracle.com ! test/ProblemList.txt ! test/java/rmi/transport/pinLastArguments/PinLastArguments.java
hg: jdk8/tl/jdk: 7123972: test/java/lang/annotation/loaderLeak/Main.java fails intermittently
Changeset: 4ad204cc7433 Author:smarks Date: 2012-07-05 15:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4ad204cc7433 7123972: test/java/lang/annotation/loaderLeak/Main.java fails intermittently Reviewed-by: dholmes, smarks Contributed-by: Eric Wang yiming.w...@oracle.com ! test/ProblemList.txt ! test/java/lang/annotation/loaderLeak/Main.java
hg: jdk8/tl/jdk: 7176907: additional warnings cleanup in java.util, java.util.regexp, java.util.zip
Changeset: b2fc66012451 Author:smarks Date: 2012-07-02 14:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b2fc66012451 7176907: additional warnings cleanup in java.util, java.util.regexp, java.util.zip Reviewed-by: forax, khazra, smarks Contributed-by: Mani Sarkar sadhak...@gmail.com ! src/share/classes/java/util/InvalidPropertiesFormatException.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/java/util/zip/GZIPInputStream.java
hg: jdk8/tl/jdk: 7170938: (str) incorrect wording in doc for String.subSequence
Changeset: 9df29b658145 Author:smarks Date: 2012-06-29 16:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9df29b658145 7170938: (str) incorrect wording in doc for String.subSequence Reviewed-by: forax, mduigou Contributed-by: Joe Bowbeer joe.bowb...@gmail.com ! src/share/classes/java/lang/String.java
hg: jdk8/tl/jdk: 7144861: speed up RMI activation tests
Changeset: f131d4361faf Author:olagneau Date: 2012-05-11 14:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f131d4361faf 7144861: speed up RMI activation tests Reviewed-by: alanb, smarks, dholmes, dmocek ! test/java/rmi/activation/checkusage/CheckUsage.java ! test/java/rmi/testlibrary/ActivationLibrary.java ! test/java/rmi/testlibrary/JavaVM.java ! test/java/rmi/testlibrary/RMID.java ! test/java/rmi/testlibrary/StreamPipe.java ! test/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java
hg: jdk8/tl/jdk: 7143230: fix warnings in java.util.jar, sun.tools.jar, zipfs demo, etc.
Changeset: 445ada5e6b4a Author:smarks Date: 2012-02-12 21:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/445ada5e6b4a 7143230: fix warnings in java.util.jar, sun.tools.jar, zipfs demo, etc. Reviewed-by: alanb, chegar, lancea, smarks Contributed-by: Mani Sarkar sadhak...@gmail.com, Michael Barker mike...@gmail.com, Carl Jokl carl.j...@gmail.com, Dinuk Weerasinghe dinu...@yahoo.com, Markus Stoy markus.s...@timgroup.com, Tom Anderson tom.ander...@timgroup.com ! src/share/classes/java/util/jar/Attributes.java ! src/share/classes/java/util/jar/JarVerifier.java ! src/share/classes/sun/tools/jar/CommandLine.java ! src/share/classes/sun/tools/jar/Manifest.java ! src/share/classes/sun/tools/jar/SignatureFile.java ! src/share/demo/management/MemoryMonitor/MemoryMonitor.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileStore.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystemProvider.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipInfo.java
hg: jdk8/tl/jdk: 7122061: add -Xlint:all -Werror to warning-free build steps
Changeset: 3a7ea63302f8 Author:smarks Date: 2011-12-29 16:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3a7ea63302f8 7122061: add -Xlint:all -Werror to warning-free build steps Reviewed-by: chegar, alanb, dholmes, ohair ! make/com/sun/demo/jvmti/hprof/Makefile ! make/com/sun/java/browser/net/Makefile ! make/com/sun/tools/Makefile ! make/com/sun/tools/attach/Makefile ! make/com/sun/tracing/Makefile ! make/com/sun/tracing/dtrace/Makefile ! make/java/instrument/Makefile ! make/java/rmi/Makefile ! make/java/text/base/Makefile ! make/java/text/bidi/Makefile ! make/java/util/Makefile ! make/javax/accessibility/Makefile ! make/javax/others/Makefile ! make/javax/security/Makefile ! make/jpda/tty/Makefile ! make/sun/launcher/Makefile ! make/sun/serialver/Makefile ! make/sun/text/Makefile ! make/sun/util/Makefile
hg: jdk8/tl/jdk: 7122235: stop the build if javac fails
Changeset: abbca81a98a7 Author:smarks Date: 2011-12-17 08:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/abbca81a98a7 7122235: stop the build if javac fails Reviewed-by: chegar, dholmes, mcimadamore, ohair ! make/common/Rules.gmk
hg: jdk8/tl/jdk: 7118546: fix warnings in javax.xml.crypto, javax.script
Changeset: 9bb7c3b97384 Author:smarks Date: 2011-12-08 14:57 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9bb7c3b97384 7118546: fix warnings in javax.xml.crypto, javax.script Reviewed-by: mullan ! src/share/classes/javax/script/ScriptException.java ! src/share/classes/javax/xml/crypto/NodeSetData.java ! src/share/classes/javax/xml/crypto/dom/DOMCryptoContext.java ! src/share/classes/javax/xml/crypto/dsig/Manifest.java ! src/share/classes/javax/xml/crypto/dsig/Reference.java ! src/share/classes/javax/xml/crypto/dsig/SignatureProperties.java ! src/share/classes/javax/xml/crypto/dsig/SignatureProperty.java ! src/share/classes/javax/xml/crypto/dsig/SignedInfo.java ! src/share/classes/javax/xml/crypto/dsig/TransformService.java ! src/share/classes/javax/xml/crypto/dsig/XMLObject.java ! src/share/classes/javax/xml/crypto/dsig/XMLSignature.java ! src/share/classes/javax/xml/crypto/dsig/XMLSignatureFactory.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/KeyInfo.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/KeyInfoFactory.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/PGPData.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/RetrievalMethod.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/X509Data.java ! src/share/classes/javax/xml/crypto/dsig/spec/ExcC14NParameterSpec.java ! src/share/classes/javax/xml/crypto/dsig/spec/XPathFilter2ParameterSpec.java ! src/share/classes/javax/xml/crypto/dsig/spec/XPathFilterParameterSpec.java ! src/share/classes/javax/xml/crypto/dsig/spec/XPathType.java
hg: jdk8/tl/jdk: 7117249: fix warnings in java.util.jar, .logging, .prefs, .zip
Changeset: 4f0f9f9c4892 Author:smarks Date: 2011-12-07 12:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4f0f9f9c4892 7117249: fix warnings in java.util.jar, .logging, .prefs, .zip Reviewed-by: alanb, dholmes, forax, sherman, smarks Contributed-by: Prasannaa prasannaa...@yahoo.com, Martijn Verburg martijnverb...@gmail.com, Goerge_Albrecht goerge.albre...@gmx.net, Graham Allan grundlefl...@googlemail.com, Michael Barker mike...@gmail.com ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/jar/Manifest.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/prefs/Preferences.java ! src/share/classes/java/util/prefs/XmlSupport.java ! src/share/classes/java/util/zip/ZipEntry.java
hg: jdk8/tl/jdk: 7116997: fix warnings in java.util.PropertyPermission
Changeset: 77f6d4360f4b Author:smarks Date: 2011-12-06 10:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/77f6d4360f4b 7116997: fix warnings in java.util.PropertyPermission Reviewed-by: smarks Contributed-by: Brandon Passanisi brandon.passan...@oracle.com ! src/share/classes/java/util/PropertyPermission.java
hg: jdk8/tl/jdk: 7116993: fix warnings in java.applet
Changeset: f4fe86bba8a2 Author:smarks Date: 2011-12-05 16:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f4fe86bba8a2 7116993: fix warnings in java.applet Reviewed-by: art, smarks Contributed-by: Danesh Dadachanji ddada...@redhat.com ! src/share/classes/java/applet/Applet.java
hg: jdk8/tl/jdk: 7116890: additional warnings fixes for java.io
Changeset: 0e3f706741ca Author:smarks Date: 2011-12-01 16:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0e3f706741ca 7116890: additional warnings fixes for java.io Reviewed-by: alanb, smarks Contributed-by: Sebastian Sickelmann sebastian.sickelm...@gmx.de ! src/share/classes/java/io/ExpiringCache.java ! src/share/classes/java/io/LineNumberInputStream.java ! src/share/classes/java/io/LineNumberReader.java ! src/share/classes/java/io/ObjectOutputStream.java ! src/share/classes/java/io/RandomAccessFile.java
hg: jdk8/tl/jdk: 7076526: add test MemoryMXBean/CollectionUsageThreshold to the problem list
Changeset: 3f66f9ca1ba5 Author:smarks Date: 2011-08-12 14:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3f66f9ca1ba5 7076526: add test MemoryMXBean/CollectionUsageThreshold to the problem list Reviewed-by: weijun, alanb ! test/ProblemList.txt
hg: jdk7/tl/jdk: 6896297: (rmi) fix ConcurrentModificationException causing TCK failure
Changeset: 00f3997e6aeb Author:smarks Date: 2011-04-20 16:30 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/00f3997e6aeb 6896297: (rmi) fix ConcurrentModificationException causing TCK failure Reviewed-by: alanb, dholmes, peterjones ! src/share/classes/sun/rmi/log/ReliableLog.java ! src/share/classes/sun/rmi/server/Activation.java
hg: jdk7/tl/jdk: 7029680: fix test/sun/misc/Version/Version.java build parsing
Changeset: f326a018fd3f Author:smarks Date: 2011-03-24 17:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f326a018fd3f 7029680: fix test/sun/misc/Version/Version.java build parsing Reviewed-by: ohair ! test/sun/misc/Version/Version.java
hg: jdk7/tl/jdk: 7022624: use try-with-resources in java.io tests
Changeset: 98d2d57d9e73 Author:smarks Date: 2011-03-01 15:05 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/98d2d57d9e73 7022624: use try-with-resources in java.io tests Reviewed-by: alanb ! test/java/io/File/SetLastModified.java ! test/java/io/FileOutputStream/AtomicAppend.java ! test/java/io/OutputStreamWriter/Encode.java ! test/java/io/PrintStream/EncodingConstructor.java ! test/java/io/PrintStream/FailingConstructors.java ! test/java/io/Serializable/evolution/RenamePackage/install/SerialDriver.java ! test/java/io/Serializable/evolution/RenamePackage/test/SerialDriver.java
hg: jdk7/tl/jdk: 7021582: convert jar/zip code and tests to use try-with-resources
Changeset: 8887cb2f5d19 Author:smarks Date: 2011-02-25 02:06 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8887cb2f5d19 7021582: convert jar/zip code and tests to use try-with-resources Reviewed-by: alanb, dholmes, sherman ! src/share/classes/java/util/jar/JarFile.java ! test/java/util/jar/JarEntry/GetMethodsReturnClones.java ! test/java/util/jar/JarFile/ScanSignedJar.java ! test/java/util/zip/Available.java ! test/java/util/zip/FileBuilder.java ! test/java/util/zip/GZIP/Accordion.java ! test/java/util/zip/GZIP/GZIPInputStreamRead.java ! test/java/util/zip/InflateIn_DeflateOut.java ! test/java/util/zip/InfoZip.java ! test/java/util/zip/LargeZip.java ! test/java/util/zip/TestEmptyZip.java ! test/java/util/zip/ZipCoding.java ! test/java/util/zip/ZipFile/Assortment.java ! test/java/util/zip/ZipFile/Comment.java ! test/java/util/zip/ZipFile/CopyJar.java ! test/java/util/zip/ZipFile/CorruptedZipFiles.java ! test/java/util/zip/ZipFile/DeleteTempJar.java ! test/java/util/zip/ZipFile/EnumAfterClose.java ! test/java/util/zip/ZipFile/GetDirEntry.java ! test/java/util/zip/ZipFile/LargeZipFile.java ! test/java/util/zip/ZipFile/ManyEntries.java ! test/java/util/zip/ZipFile/ManyZipFiles.java ! test/java/util/zip/ZipFile/ReadAfterClose.java ! test/java/util/zip/ZipFile/ReadZip.java ! test/java/util/zip/ZipFile/ShortRead.java ! test/java/util/zip/zip.java
hg: jdk7/tl/jdk: 7018385: update javax.sql classes to use try-with-resources
Changeset: 5bf920749b97 Author:smarks Date: 2011-02-18 12:43 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5bf920749b97 7018385: update javax.sql classes to use try-with-resources Reviewed-by: alanb, lancea, darcy ! src/share/classes/javax/sql/rowset/serial/SerialClob.java ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java
hg: jdk7/tl/jdk: 7018392: update URLJarFile.java to use try-with-resources
Changeset: 6e33b377aa6e Author:smarks Date: 2011-02-16 18:22 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6e33b377aa6e 7018392: update URLJarFile.java to use try-with-resources Reviewed-by: alanb, chegar, hawtin ! src/share/classes/sun/net/www/protocol/jar/URLJarFile.java
hg: jdk7/tl/jdk: 7012003: diamond conversion for ssl
Changeset: d61d9bf190f5 Author:smarks Date: 2011-01-14 15:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d61d9bf190f5 7012003: diamond conversion for ssl Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/CipherSuiteList.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/DefaultSSLContextImpl.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/HelloExtensions.java ! src/share/classes/sun/security/ssl/ProtocolList.java ! src/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java ! src/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java ! src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java ! src/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java ! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHandlerTest.java
hg: jdk7/tl/jdk: 7008713: diamond conversion of kerberos5 and security tools
Changeset: a5a22f93e4c5 Author:smarks Date: 2011-01-12 13:52 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a5a22f93e4c5 7008713: diamond conversion of kerberos5 and security tools Reviewed-by: weijun ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/security/krb5/PrincipalName.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/internal/Authenticator.java ! src/share/classes/sun/security/krb5/internal/AuthorizationData.java ! src/share/classes/sun/security/krb5/internal/EncAPRepPart.java ! src/share/classes/sun/security/krb5/internal/HostAddresses.java ! src/share/classes/sun/security/krb5/internal/KDCReq.java ! src/share/classes/sun/security/krb5/internal/KDCReqBody.java ! src/share/classes/sun/security/krb5/internal/KRBCred.java ! src/share/classes/sun/security/krb5/internal/KRBError.java ! src/share/classes/sun/security/krb5/internal/KrbCredInfo.java ! src/share/classes/sun/security/krb5/internal/LastReq.java ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java ! src/share/classes/sun/security/krb5/internal/crypto/EType.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/share/classes/sun/security/tools/JarSigner.java ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/tools/policytool/PolicyTool.java ! test/sun/security/krb5/IPv6.java ! test/sun/security/krb5/auto/CleanState.java ! test/sun/security/krb5/auto/Context.java ! test/sun/security/krb5/auto/HttpNegotiateServer.java ! test/sun/security/krb5/auto/KDC.java ! test/sun/security/krb5/auto/LoginModuleOptions.java ! test/sun/security/krb5/tools/KtabCheck.java
hg: jdk7/tl/jdk: 7005608: diamond conversion of JCA and crypto providers
Changeset: 2a0ff59928de Author:smarks Date: 2011-01-10 17:06 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2a0ff59928de 7005608: diamond conversion of JCA and crypto providers Reviewed-by: wetmore ! src/share/classes/java/security/Security.java ! src/share/classes/sun/security/jca/ProviderList.java ! src/share/classes/sun/security/jca/Providers.java ! src/share/classes/sun/security/provider/PolicyFile.java ! src/share/classes/sun/security/provider/Sun.java ! src/share/classes/sun/security/provider/VerificationProvider.java ! src/share/classes/sun/security/provider/X509Factory.java ! src/share/classes/sun/security/rsa/RSACore.java ! src/share/classes/sun/security/rsa/SunRsaSign.java
hg: jdk7/tl/jdk: 7008728: diamond conversion of basic security, permissions, authentication
Changeset: 3dbc783a8073 Author:smarks Date: 2011-01-07 15:39 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3dbc783a8073 7008728: diamond conversion of basic security, permissions, authentication Reviewed-by: mullan ! src/share/classes/com/sun/security/auth/PolicyFile.java ! src/share/classes/com/sun/security/auth/callback/DialogCallbackHandler.java ! src/share/classes/com/sun/security/auth/login/ConfigFile.java ! src/share/classes/com/sun/security/auth/module/JndiLoginModule.java ! src/share/classes/com/sun/security/auth/module/KeyStoreLoginModule.java ! src/share/classes/com/sun/security/auth/module/SolarisLoginModule.java ! src/share/classes/com/sun/security/auth/module/UnixLoginModule.java ! src/share/classes/java/security/AccessControlContext.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/security/CodeSource.java ! src/share/classes/java/security/Permissions.java ! src/share/classes/java/security/ProtectionDomain.java ! src/share/classes/java/security/Provider.java ! src/share/classes/java/security/SecureClassLoader.java ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/UnresolvedPermission.java ! src/share/classes/java/security/UnresolvedPermissionCollection.java ! src/share/classes/javax/security/auth/PrivateCredentialPermission.java ! src/share/classes/javax/security/auth/SubjectDomainCombiner.java ! src/share/classes/javax/security/auth/kerberos/DelegationPermission.java ! src/share/classes/javax/security/auth/kerberos/ServicePermission.java ! src/share/classes/sun/security/acl/AclEntryImpl.java ! src/share/classes/sun/security/acl/AclImpl.java ! src/share/classes/sun/security/acl/GroupImpl.java ! test/com/sun/security/auth/module/LdapLoginModule/CheckConfigs.java ! test/com/sun/security/auth/module/LdapLoginModule/CheckOptions.java
