> Add `java.io.PrintOutput` to represent print operations, and modify
> `java.io.PrintStream` and `java.io.PrintWriter` to implement it.
Tingjun Yuan has updated the pull request incrementally with one additional
commit since the last revision:
Fix grammar mistakes in the doc
-
Add `java.io.PrintOutput` to represent print operations, and modify
`java.io.PrintStream` and `java.io.PrintWriter` to implement it.
-
Commit messages:
- remove `@since 1.5`
- Make PrintWriter implement PrintOutput
- Make PrintStream implement PrintOutput
- Create PrintOutput.jav
> Adding the following methods to check the nullity of elements of an array or
> a collection:
>
>
> java.util.Arrays:
> public static E[] requireNoNulls(E[] array)
> public static E[] requireNoNulls(E[] array, String message)
> public static E[] requireNoNulls(E[] array, IntFunction
> messa
> Adding the following methods to check the nullity of elements of an array or
> a collection:
>
>
> java.util.Arrays:
> public static E[] requireNoNulls(E[] array)
> public static E[] requireNoNulls(E[] array, String message)
> public static E[] requireNoNulls(E[] array, IntFunction
> messa
> Adding the following methods to check the nullity of elements of an array or
> a collection:
>
>
> java.util.Arrays:
> public static E[] requireNoNulls(E[] array)
> public static E[] requireNoNulls(E[] array, String message)
> public static E[] requireNoNulls(E[] array, IntFunction
> messa
Adding the following methods to check the nullity of elements of an array or a
collection:
java.util.Arrays:
public static E[] requireNoNulls(E[] array)
public static E[] requireNoNulls(E[] array, String message)
public static E[] requireNoNulls(E[] array, IntFunction
messageGenerator)
publi
On Fri, 2 Dec 2022 16:40:51 GMT, Magnus Ihse Bursie wrote:
> According to [the
> specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader))
> trailing whitespaces in the values of properties files are (somewhat
> surprisingly) ac
> This is the javadoc of `JavaLangAccess::newStringNoRepl`:
>
>
> /**
> * Constructs a new {@code String} by decoding the specified subarray of
> * bytes using the specified {@linkplain java.nio.charset.Charset
> charset}.
> *
> * The caller of this method shall relinquis
> This is the javadoc of `JavaLangAccess::newStringNoRepl`:
>
>
> /**
> * Constructs a new {@code String} by decoding the specified subarray of
> * bytes using the specified {@linkplain java.nio.charset.Charset
> charset}.
> *
> * The caller of this method shall relinquis
On Sat, 28 Jan 2023 19:28:46 GMT, Roger Riggs wrote:
> The parameter will be easier to understand if `true` means that the string
> created must not share the byte array supplied. For example,
>
> @param noShare {@code true} if the resulting string MUST NOT share the byte
> array, {@code false
> This is the javadoc of `JavaLangAccess::newStringNoRepl`:
>
>
> /**
> * Constructs a new {@code String} by decoding the specified subarray of
> * bytes using the specified {@linkplain java.nio.charset.Charset
> charset}.
> *
> * The caller of this method shall relinquis
On Fri, 20 Jan 2023 16:47:27 GMT, Glavo wrote:
> This is the javadoc of `JavaLangAccess::newStringNoRepl`:
>
>
> /**
> * Constructs a new {@code String} by decoding the specified subarray of
> * bytes using the specified {@linkplain java.nio.charset.Charset
> charset}.
> *
>
On Sat, Jan 28, 2023 at 6:06 PM Alan Bateman
wrote:
> 8k is the threshold at which RAF spills into a temporary malloc'ed
> buffer for the I/O operation. At some point the RAF implementation will
> be replaced (we need to do this for a Project Loom), but in the mean
> time, it probably would requi
On Sat, Jan 28, 2023 at 5:29 PM Lance Andersen
wrote:
> I think it is fine to move the validation immediately following findEND()
> though I am not sure there is a big win overall.
>
> I also would prefer to see the test based off of an actual ZIP(or at least
> have the current/modified version o
On 27/01/2023 23:23, Eirik Bjørsnøs wrote:
:
If this is safe to remove, I'm happy to submit a PR. But code like
this is usually there for a reason..?
8k is the threshold at which RAF spills into a temporary malloc'ed
buffer for the I/O operation. At some point the RAF implementation will
be
> On Jan 27, 2023, at 2:46 AM, Tagir Valeev wrote:
>
> …
>>
>>
>> public static int clamp(long value, int min, int max)
>> public static long clamp(long value, long min, long max)
>> public static double clamp(double value, double min, double max)
>> public static float clamp(double value, fl
I think it is fine to move the validation immediately following findEND()
though I am not sure there is a big win overall.
I also would prefer to see the test based off of an actual ZIP(or at least have
the current/modified version of the test). I would prefer to avoid having
another place wh
I also posted a CSR draft:
https://bugs.openjdk.org/browse/JDK-8301301
On Fri, Jan 27, 2023 at 11:46 AM Tagir Valeev wrote:
>
> Hello, all!
>
> Thank you for an interesting discussion. As I see some interest
> towards this feature, I've created a new issue to track this:
> https://bugs.openjdk.or
On Sat, 28 Jan 2023 15:34:07 GMT, Rémi Forax wrote:
> This may change the startup time a lot because initializing the annotation
> parser (and the factory around) and creating the annotations is quite slow.
Another option is to create a class list of trusted collection types.
I will test it l
On Sat, Jan 28, 2023 at 4:47 PM Alan Bateman
wrote:
> The intention of the test was exercise a multi-GB CEN. So I think it
>
would be great if it could be re-written as an automatic test but I
> think it should be a real ZIP file, make use of sparse files might help.
>
Alan,
Yes, this change do
On 26/01/2023 18:57, Eirik Bjørsnøs wrote:
Hi,
This PR updates the test TestTooManyEntries to not create gigabytes of
ZIP files, allowing the test to run fast and non-manual:
https://github.com/openjdk/jdk/pull/12231
May I please get some help with filing a JBS for this PR?
The intention of th
On Fri, 27 Jan 2023 13:53:45 GMT, Glavo wrote:
>> I checked the `java.base` module, and all the `Collection#toArray()` method
>> of collections be implemented correctly.
>>
>> Their return values can be trusted, so many unnecessary array duplication
>> can be eliminated.
>
> Glavo has updated
>
> Please review the following PR which suggests updating the field access
> methods in ZipUtils to use the VarHandle API
> https://github.com/openjdk/jdk/pull/12273
>
Never mind, Claes pointed out that VarHandles may take some time to warp up
and we did indeed measure a regression for cold-start
On Fri, 27 Jan 2023 21:02:25 GMT, Glavo wrote:
> I think the simplest solution is to have a non public interface declared
> inside java.util. Like java.util.RandomAccess, but non public. The main
> advantage to use an interface is that you can document it and it's easy to
> find all the implem
On Sat, 28 Jan 2023 09:05:04 GMT, Alan Bateman wrote:
> The proposals so far in this PR have major security implications. It's not
> clear to me this is the right PR to expand into defining a JDK internal
> notion of trusted collection. I don't wish to discourage contributors in this
> area bu
Hi,
Please review the following PR which suggests updating the field access
methods in ZipUtils to use the VarHandle API when reading multibyte values
from byte arrays:
https://github.com/openjdk/jdk/pull/12273
Thanks,
Eirik.
On Fri, 27 Jan 2023 21:02:25 GMT, Glavo wrote:
> I think this is feasible, but it should be placed in a sub-package in
> `jdk.internal`, because some trusted collections are outside `java.util`.
The proposals so far in this PR have major security implications. It's not
clear to me this is the
27 matches
Mail list logo
