On Mon, 12 Oct 2020 13:47:46 GMT, Chris Hegarty wrote:
> TL;DR add EnumSet::readObjectNoData()
>
> EnumSet is an exemplar of the Serialization Proxy Pattern. As such, it
> should strictly implement that pattern and demonstrate how best to
> defend against inappropriate instantiation through dese
On Thu, 15 Oct 2020 22:39:50 GMT, Coleen Phillimore wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Re-add file erroneously deleted (detected as rename)
>
> src/hotspot/cpu/x86/foreign_globals_x86.cpp line 2
> This patch contains the changes associated with the third incubation round of
> the foreign memory access API incubation
> (see JEP 393 [1]). This iteration focus on improving the usability of the API
> in 3 main ways:
> * first, by providing a way to obtain truly *shared* segments, which can b
On Thu, 15 Oct 2020 22:44:54 GMT, Coleen Phillimore wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Re-add file erroneously deleted (detected as rename)
>
> src/hotspot/cpu/x86/foreign_globals_x86.hpp line 3
On Thu, 15 Oct 2020 22:52:14 GMT, Coleen Phillimore wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Re-add file erroneously deleted (detected as rename)
>
> src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line
On Thu, 15 Oct 2020 22:42:49 GMT, Coleen Phillimore wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Re-add file erroneously deleted (detected as rename)
>
> src/hotspot/cpu/x86/foreign_globals_x86.cpp line 5
On Thu, 15 Oct 2020 18:22:12 GMT, Roger Riggs wrote:
>> Marked as reviewed by dfuchs (Reviewer).
>
> Please review the corresponding CSR:
> https://bugs.openjdk.java.net/browse/JDK-8251991
Hi Roger,
This looks very good.
I have a few minor comments:
1. Add an explicit type parameter to t
> Hi,
>
> this is the continuation of the review of the implementation for:
>
> https://bugs.openjdk.java.net/browse/JDK-8227745
> https://bugs.openjdk.java.net/browse/JDK-8233915
>
> It allows for JIT optimizations based on escape analysis even if JVMTI agents
> acquire capabilities to access
On Fri, 16 Oct 2020 11:46:47 GMT, Chris Hegarty wrote:
>> Please review the corresponding CSR:
>> https://bugs.openjdk.java.net/browse/JDK-8251991
>
> Hi Roger,
>
> This looks very good.
>
> I have a few minor comments:
>
> 1. Add an explicit type parameter to toHexDigits
> 2. Some clean
On Fri, 16 Oct 2020 13:10:24 GMT, Chris Hegarty wrote:
> Maybe I'm being too pedantic, but is the use of the term _copy_ for the
> withers overly prescriptive, and possibly
> limiting an implementation? For example, for `withDelimiter` does _copy_
> preclude such an implementation:
> ```
>
On Fri, 16 Oct 2020 14:00:38 GMT, Roger Riggs wrote:
>> Maybe I'm being too pedantic, but is the use of the term _copy_ for the
>> withers overly prescriptive, and possibly
>> limiting an implementation? For example, for `withDelimiter` does _copy_
>> preclude such an implementation:
>> /*
On Fri, 16 Oct 2020 14:00:38 GMT, Roger Riggs wrote:
> Since the instances are immutable, it seemed useful to emphasize that only
> the instance returned has the requested
> change. Discarding the return value was incorrect programming. The original
> instance is not modified.
Understood, and
On Fri, 16 Oct 2020 14:24:41 GMT, Chris Hegarty wrote:
>>> Maybe I'm being too pedantic, but is the use of the term _copy_ for the
>>> withers overly prescriptive, and possibly
>>> limiting an implementation? For example, for `withDelimiter` does _copy_
>>> preclude such an implementation:
>>>
On Thu, 15 Oct 2020 18:30:20 GMT, Mandy Chung wrote:
>> Hi Mandy,
>>
>> I'm beginning to think that we somewhat wondered away from the original
>> intent which was to mimic the bytecode
>> behaviour as much as possible. Bytecode behaviour for super calls
>> (invokespecial) is very special and
On Fri, 16 Oct 2020 05:41:17 GMT, David Holmes wrote:
>> Kim Barrett 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 11 additional commits sin
On Fri, 16 Oct 2020 14:46:11 GMT, Roger Riggs wrote:
>>> Since the instances are immutable, it seemed useful to emphasize that only
>>> the instance returned has the requested
>>> change. Discarding the return value was incorrect programming. The original
>>> instance is not modified.
>>
>> Un
This is an update to javac and javadoc, to introduce support for Preview APIs,
and generally improve javac and javadoc
behavior to more closely adhere to JEP 12.
The notable changes are:
* adding support for Preview APIs (javac until now supported primarily only
preview language features, and
On Fri, 16 Oct 2020 15:22:37 GMT, Roger Riggs wrote:
>> The HexFormat API currently uses an indexing model for arrays and strings
>> based on an index and a length.
>> Many other APIs in the JDK use an index model of `fromIndex` and `toIndex`
>> (exclusive).
>>
>> They are equivalent and conve
On Fri, 16 Oct 2020 15:20:03 GMT, Jan Lahoda wrote:
> This is an update to javac and javadoc, to introduce support for Preview
> APIs, and generally improve javac and javadoc
> behavior to more closely adhere to JEP 12.
> The notable changes are:
>
> * adding support for Preview APIs (javac un
On Fri, 16 Oct 2020 15:20:03 GMT, Jan Lahoda wrote:
> This is an update to javac and javadoc, to introduce support for Preview
> APIs, and generally improve javac and javadoc
> behavior to more closely adhere to JEP 12.
> The notable changes are:
>
> * adding support for Preview APIs (javac un
On Thu, 15 Oct 2020 17:04:37 GMT, Kim Barrett wrote:
>> Finally returning to this review that was started in April 2020. I've
>> recast it as a github PR. I think the security concern raised by Gil
>> has been adequately answered.
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-A
On Fri, 16 Oct 2020 15:20:03 GMT, Jan Lahoda wrote:
> This is an update to javac and javadoc, to introduce support for Preview
> APIs, and generally improve javac and javadoc
> behavior to more closely adhere to JEP 12.
> The notable changes are:
>
> * adding support for Preview APIs (javac un
JDK-8254843: Exception launching app on windows in some cases
loading splashscreen.dll in WinLaunchercpp would load java.dll from path
instead of runtime/bin causing jni launcher to
crash. instead we just use what used to be the fallback, using
loadDllWithAddDllDirectory().
-
Commit
On Fri, 16 Oct 2020 14:46:59 GMT, Peter Levart wrote:
>> Hi Peter,
>>
>> The current `newProxyInstance` API does not perform access check against the
>> proxy interfaces.I want to avoid
>> adding new caller-sensitive method where possible. I did consider any
>> alternative to make it non
On Wed, 14 Oct 2020 18:15:19 GMT, Daniel Fuchs wrote:
>> For the common cases, the application should know the type of the referent
>> and using `T` in `refersTo` will benefit
>> from the compiler type checking. For the unknown type case, cast to
>> `Reference` is not ideal but reasonable?
>>
On Fri, 16 Oct 2020 18:27:31 GMT, Peter Levart wrote:
>> That sounds reasonable to me. Thanks for looking into it.
>
> I just want to note that if you have a `Reference ref` at hand, you
> can not just do:
> Referemce r = (Reference) ref;
> ...since those generic types are not related. You have
On Fri, 16 Oct 2020 17:59:14 GMT, Andy Herrick wrote:
> JDK-8254843: Exception launching app on windows in some cases
> loading splashscreen.dll in WinLaunchercpp would load java.dll from path
> instead of runtime/bin causing jni launcher to
> crash. instead we just use what used to be the fallb
... is replaced with {@code ...} in java.sql classes.
Please review and sponsor this change.
-
Commit messages:
- JDK-8253936 Replace ... with {@code ...} for java.sql
Changes: https://git.openjdk.java.net/jdk/pull/707/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=707
> java.util.HexFormat utility:
>
> - Format and parse hexadecimal strings, with parameters for delimiter,
> prefix, suffix and upper/lowercase
> - Static factories and builder methods to create HexFormat copies with
> modified parameters.
> - Consistent naming of methods for conversion of byt
Hi Vipin,
Have you generated the javadocs for this change? If not I will pull the
changes over this weekend and take a look
> On Oct 16, 2020, at 3:45 PM, Vipin Sharma wrote:
>
> ... is replaced with {@code ...} in java.sql classes.
> Please review and sponsor this change.
>
> -
> Following up on archiving lambda proxy classes in dynamic CDS archive
> ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE
> adds the functionality of archiving of
> lambda proxy classes in static CDS archive.
> When the -XX:DumpLoadedClassList is enabled, the constant p
On Wed, 14 Oct 2020 16:24:47 GMT, Calvin Cheung wrote:
>>> `@lambda-proxy: LambHello run ()Ljava/lang/Runnable; ()V 6 LambHello
>>> lambda$main$0 ()V ()V`
>>
>> Can you explain the format?
>
> `@lambda-proxy LambHello run ()Ljava/lang/Runnable; ()V REF_invokeStatic
> LambHello lambda$main$0 (
On Fri, 16 Oct 2020 21:25:04 GMT, Mandy Chung wrote:
>> `@lambda-proxy LambHello run ()Ljava/lang/Runnable; ()V REF_invokeStatic
>> LambHello lambda$main$0 ()V ()V`
>> means
>> `@lambda-proxy
>>
>> `
>> It is a symbolic representation of a invoke dynamic constant pool entry.
>> public
On Fri, 16 Oct 2020 17:59:14 GMT, Andy Herrick wrote:
> JDK-8254843: Exception launching app on windows in some cases
> loading splashscreen.dll in WinLaunchercpp would load java.dll from path
> instead of runtime/bin causing jni launcher to
> crash. instead we just use what used to be the fallb
On Fri, 16 Oct 2020 17:59:14 GMT, Andy Herrick wrote:
> JDK-8254843: Exception launching app on windows in some cases
> loading splashscreen.dll in WinLaunchercpp would load java.dll from path
> instead of runtime/bin causing jni launcher to
> crash. instead we just use what used to be the fallb
On Wed, 14 Oct 2020 14:20:11 GMT, Raffaello Giulietti
wrote:
>> Hello
>>
>> this is a gentle reminder that this issue still needs a more formal review.
>>
>> Greetings
>> Raffaello
>
> Hello,
>
> a reminder that this issue has not been formally reviewed.
> Estimated time: 10-15 min with "Hack
On Tue, 13 Oct 2020 16:17:49 GMT, Stuart Marks wrote:
>> Perhaps I should clarify my previous comment. When I said "implementation"
>> what I meant was that pseudo-code inside the
>> `@implSpec` tag, not the actual body of `default V compute(K key,
>> BiFunction
>> remappingFunction)`.
>
> This
On Sat, 17 Oct 2020 02:40:35 GMT, John Lin
wrote:
>> This change is to a normative portion of the specification, and as such will
>> require a CSR.
>
> Hi @pavelrappo & @stuart-marks,
>
> Thank you for the review. When I first proposed this patch in the mailing
> list, the patch looked like t
This is from the mailing list:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067190.html
-
### Progress
- [x] Change must not contain extraneous whitespace
- [x] Commit message must refer to an issue
- [ ] Change must be properly reviewed
### Testing
| | Linux x64 |
39 matches
Mail list logo
