Finally getting back to this after some internal discussion that
dragged along because folks have been busy.
> On Apr 8, 2020, at 12:05 PM, Gil Tene wrote:
>
> Lifting out of response from the JIRA issue:
>
> I always worry when proposing a change to an existing invariant, and
>
2020/8/20 13:59:39 -0700, roger.ri...@oracle.com:
> On 8/20/20 3:10 PM, mark.reinh...@oracle.com wrote:
>> ...
>>
>> A few comments:
>>
>> - Why do the short-form `encoder` factory methods return encoders that
>> produce upper-case hex strings? `Integer::toHexString` and other
>>
Ah, I was looking for that kind of information in the bug report, but
couldn't find any.
/Erik
On 2020-08-25 13:20, Joe Wang wrote:
Hi Erik,
We're acting on a report Jon generated separately. The warnings checks
are currently disabled (see line 106 JAVADOC_DISABLED_DOCLINT :=
accessibility
Hi Erik,
We're acting on a report Jon generated separately. The warnings checks
are currently disabled (see line 106 JAVADOC_DISABLED_DOCLINT :=
accessibility html missing syntax reference).
-Joe
On 8/25/20 12:39 PM, Erik Joelsson wrote:
On 2020-08-25 12:21, Roger Riggs wrote:
Hi Erik,
Hi Erik,
We're in a cleanup phase of the source before re-enabling disabled warnings.
The warnings for "missing" comments are disabled:
Docs.gmk:
106: JAVADOC_DISABLED_DOCLINT := accessibility html missing syntax reference
Roger
On 8/25/20 3:39 PM, Erik Joelsson wrote:
On 2020-08-25
+1
Naoto
On 8/25/20 11:47 AM, Joe Wang wrote:
Cc-ing build-...@openjdk.java.net (makefile change: make/Docs.gmk)
Updated webrev: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/
Thanks Roger! Please see inline comments.
On 8/25/20 8:09 AM, Roger Riggs wrote:
Hi Joe,
Eliminating
On 2020-08-25 12:21, Roger Riggs wrote:
Hi Erik,
org.w3c is in third party code that is not being updated. There is a
balance between
ignoring the warnings and doing a bunch of editing that would
overwritten by a future update.
Yes, I get that part, but why are those warnings not
Hi Joe,
The updates to those files are fine, I mixed up the two packages.
Roger
On 8/25/20 2:47 PM, Joe Wang wrote:
org/xml/...: If we're suppressing the warnings for org/xml/... then
the files changes are unnecessary?
Did you mean org/w3c? We're only suppressing the warnings for org/w3c
Hi Erik,
org.w3c is in third party code that is not being updated. There is a
balance between
ignoring the warnings and doing a bunch of editing that would
overwritten by a future update.
$.02, Roger
On 8/25/20 2:58 PM, Erik Joelsson wrote:
Build change looks ok, but why is it needed? You
Hi Aleksei,
LGTM.
You could also add the @Seial annotation to serialVersionUID
declarations.
best regards,
-- daniel
On 25/08/2020 16:03, Aleks Efimov wrote:
Hi,
The documentation of classes from "java.naming" module needs to be
improved to resolve javadoc -Xdoclint "no comment" warnings.
Hi Aleksei,
CompositeName.java readObject and writeObject methods should have a
generic first line comment.
CompositeName.java
BasicAttribute.java
BasicAttributes.java
For example,
* The WriteObject method is called to save the state of the
FilePermission to a stream.
* The readObject
HI, Ioi
Thanks for the re-review, updated webrev:
http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-04/
Changed according to your suggestion, the only a little difference is move
traceResolve(String line) to InvokerBytecodeGenerator as a static package
public function so other
Build change looks ok, but why is it needed? You are fixing a bunch of
warnings in one part of the source and disabling them in another part.
Is there some other change incoming that will enable more warning
categories by default?
/Erik
On 2020-08-25 11:47, Joe Wang wrote:
Cc-ing
Cc-ing build-...@openjdk.java.net (makefile change: make/Docs.gmk)
Updated webrev: http://cr.openjdk.java.net/~joehw/jdk16/8251561/webrev_04/
Thanks Roger! Please see inline comments.
On 8/25/20 8:09 AM, Roger Riggs wrote:
Hi Joe,
Eliminating the checking for warnings in org.w3c is fine.
Hi Aleksei
The changes look good
> On Aug 25, 2020, at 11:03 AM, Aleks Efimov wrote:
>
> Hi,
>
> The documentation of classes from "java.naming" module needs to be improved
> to resolve javadoc -Xdoclint "no comment" warnings.
>
> JBS issue: https://bugs.openjdk.java.net/browse/JDK-8251182
On 8/25/20 3:16 AM, Gilles Duboscq wrote:
Since this patch caches a singleton instance in the generated class,
it could apply to the eager initialization case as well and replace
the current use of core reflection to new an instance except that the
target of the returning callsite would
Hello,
Could your review the fix for the issue:
Bug: https://bugs.openjdk.java.net/browse/JDK-8252248
Fix: http://cr.openjdk.java.net/~alexsch/8252248/webrev.00/
Building JDK on Alpine Linux with musl libc gives the error:
src/java.base/linux/native/libnet/linux_close.c:63:25: error:
Hi Joe,
Eliminating the checking for warnings in org.w3c is fine. Please be more
specific in the comment.
"Ignore the doclint warnings in the W3C DOM package"
org/xml/...: If we're suppressing the warnings for org/xml/... then the
files changes are unnecessary?
Remove the addition of
Hi,
The documentation of classes from "java.naming" module needs to be
improved to resolve javadoc -Xdoclint "no comment" warnings.
JBS issue: https://bugs.openjdk.java.net/browse/JDK-8251182
Webrev: http://cr.openjdk.java.net/~aefimov/8251182/00/index.html
CSR:
Hi Ioi,
Changes looks really good. Comments interspersed below.
Thanks,
Lois
On 8/12/2020 6:06 PM, Ioi Lam wrote:
Hi Lois,
Thanks for the comments. I have an updated webrev
http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v02/
Should this patch be a workaround to existing releases rather than
the main line? As Brian mentions, lambda proxy class may become
inline class in valhalla repo (Roger has a patch already). The
earlier fixing those programs the better.
Indeed if we know this is landing in this cycle
Hi Corey,
If there's a performance issue, that's an option.
Though its tempting to add intrinsics for each supported instruction
set, it adds code
that has to be maintained forever, so it best to wait till its
determined to be a bottleneck.
Most of the cases I've seen in the code are fairly
Hi Corey,
thanks for proposing this change. I have comments and suggestions regarding
various files.
Base64.java
This is the only file which needs another review from core-libs-dev.
First of all, I like the idea to use a HotSpotIntrinsicCandidate which can
consume as many bytes as the
Hi Mandy,
Thanks for the comments.
On 24/06/2020 02:56, Mandy Chung wrote:
Hi Gilles,
Additional comments:
215 try {
216 return new ConstantCallSite(Lookup.IMPL_LOOKUP.findStaticGetter(innerClass,
LAMBDA_INSTANCE_FIELD, invokedType.returnType()));
217 } catch (ReflectiveOperationException
24 matches
Mail list logo
