> Please take a look at it.
>
> Naoto
>
> On 3/3/20 3:30 PM, Stephen Colebourne wrote:
> > I fear more changes are needed here.
> >
> > 1) The code is isFixedOffset() is indeed wrong, but the fix is
> > insufficient. The zone is fixed if baseStandardOffset
Fine by me, but I'm not an OpenJDK Reviewer
Stephen
On Mon, 9 Mar 2020 at 03:05, wrote:
>
> Thanks, Stephen.
>
> Updated the webrev for those two suggestions:
>
> http://cr.openjdk.java.net/~naoto/8239836/webrev.04/
>
> Naoto
>
> On 3/8/20 4:22 PM, Stephen Colebourn
+1
Stephen
On Wed, 6 May 2020 at 21:50, wrote:
>
> Hello,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8244245
>
> The CSR and proposed changeset are located at:
>
> https://bugs.openjdk.java.net/browse/JDK-8244246
>
On Thu, 7 May 2020 at 07:38, Joe Wang wrote:
> The Javadoc states:
> If the locale contains the "ca" (calendar), "nu" (numbering
> system), "rg" (region override), and/or "tz" (timezone) Unicode
> extensions, the chronology, numbering system and/or the zone are overridden.
>
> If you remove
I'm not an official OpenJDK reviewer, nor would I be confident
reviewing the native code here.
Stephen
On Tue, 26 May 2020 at 14:28, David Holmes wrote:
>
> On 26/05/2020 6:14 pm, Stephen Colebourne wrote:
> > AFAICT a nanosecond clock is fine from a java.time.* API perspective
AFAICT a nanosecond clock is fine from a java.time.* API perspective.
Stephen
On Tue, 26 May 2020 at 06:01, David Holmes wrote:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8242504
> webrev: http://cr.openjdk.java.net/~dholmes/8242504/webrev/
>
> This work was contributed by Mark
+1
Stephen
On Thu, 30 Jul 2020 at 22:54, wrote:
>
> Hi,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8233048
>
> The proposed chageset is located at:
>
> https://cr.openjdk.java.net/~naoto/8233048/webrev.00/
>
> java.time.temporal.WeekFields.ISO
On Mon, 23 Nov 2020 19:24:51 GMT, Naoto Sato wrote:
> Hi,
>
> Please review this simple doc fix. Thanks.
Marked as reviewed by scolebourne (Author).
-
PR: https://git.openjdk.java.net/jdk/pull/1399
On Tue, 10 Nov 2020 19:52:14 GMT, Naoto Sato wrote:
>> Hi,
>>
>> Please review the changes for the subject issue. This is to enhance the
>> java.time package to support day periods, such as "in the morning", defined
>> in CLDR. It will add a new pattern character 'B' and its supporting
On Thu, 12 Nov 2020 20:03:14 GMT, Naoto Sato wrote:
>> Hi,
>>
>> Please review the changes for the subject issue. This is to enhance the
>> java.time package to support day periods, such as "in the morning", defined
>> in CLDR. It will add a new pattern character 'B' and its supporting
On Thu, 5 Nov 2020 23:24:19 GMT, Stephen Colebourne
wrote:
>> I implemented what you suggested here in the latest PR, but that would be a
>> behavioral change which requires a CSR, as "AM" would be resolved to 06:00
>> which was not before. Do you think it w
On Fri, 30 Oct 2020 22:03:08 GMT, Naoto Sato wrote:
>> Hi,
>>
>> Please review the changes for the subject issue. This is to enhance the
>> java.time package to support day periods, such as "in the morning", defined
>> in CLDR. It will add a new pattern character 'B' and its supporting
On Fri, 30 Oct 2020 21:30:50 GMT, Naoto Sato wrote:
>> src/java.base/share/classes/java/time/format/Parsed.java line 472:
>>
>>> 470: }
>>> 471: if (dayPeriod != null) {
>>> 472: if (fieldValues.containsKey(HOUR_OF_DAY)) {
>>
>> Are we certain that the CLDR data
On Fri, 30 Oct 2020 11:06:59 GMT, Stephen Colebourne
wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixed exception messages.
>
> src/java.base/share/classes/java/time/format/P
On Tue, 3 Nov 2020 01:33:32 GMT, Stuart Marks wrote:
> This change introduces a new terminal operation on Stream. This looks like a
> convenience method for Stream.collect(Collectors.toList()) or
> Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this
> method directly on
On Thu, 29 Oct 2020 15:59:51 GMT, Naoto Sato wrote:
> Hi,
>
> Please review the changes for the subject issue. This is to enhance the
> java.time package to support day periods, such as "in the morning", defined
> in CLDR. It will add a new pattern character 'B' and its supporting builder
>
On Mon, 2 Nov 2020 23:21:22 GMT, Naoto Sato wrote:
>> Pulling on this a little more.
>>
>> As the PR stands, it seems that if the user passes in text with just a
>> day-period of "AM" they get a `LocalTime` of 06:00 but if they pass in
>> `AMPM_OF_DAY` of "AM" the get no `LocalTime` in the
On Thu, 5 Nov 2020 17:12:11 GMT, Naoto Sato wrote:
>> Hi,
>>
>> Please review the changes for the subject issue. This is to enhance the
>> java.time package to support day periods, such as "in the morning", defined
>> in CLDR. It will add a new pattern character 'B' and its supporting builder
On Fri, 6 Nov 2020 03:00:52 GMT, Naoto Sato wrote:
>> test/jdk/java/time/tck/java/time/format/TCKDateTimeParseResolver.java line
>> 858:
>>
>>> 856: return new Object[][]{
>>> 857: {STRICT, 0, LocalTime.of(6, 0), 0},
>>> 858: {STRICT, 1, LocalTime.of(18,
On Wed, 16 Jun 2021 10:57:07 GMT, Patrick Concannon
wrote:
>> Hi,
>>
>> Could someone please review my code for updating the code in the `java.time`
>> packages to make use of the switch expressions?
>>
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request with a new
On Wed, 16 Jun 2021 11:11:30 GMT, Chris Hegarty wrote:
>> src/java.base/share/classes/java/time/Month.java line 480:
>>
>>> 478: int leap = leapYear ? 1 : 0;
>>> 479: return switch (this) {
>>> 480: case JANUARY -> 1;
>>
>> Unnecessary alignment
>
> The vertical
On Thu, 17 Jun 2021 13:56:00 GMT, Daniel Fuchs wrote:
>> It is your codebase, not mine, so it is up to you. Aligning things by column
>> is generally frowned on in most style guides because it handles refactoring
>> poorly, resulting in lots of needless change (or people forgetting to
>>
On Mon, 21 Jun 2021 18:22:26 GMT, Naoto Sato wrote:
> Please review this doc clarification fix to `toDaysPart()` method. CSR will
> also be filed accordingly.
Marked as reviewed by scolebourne (Author).
-
PR: https://git.openjdk.java.net/jdk/pull/4542
On Tue, 15 Jun 2021 at 15:16, wrote:
> Comparison
> --
> boolean isGreaterThan(Duration duration) / isLongerThan(..)
> boolean isSmallerThan(Duration duration) / isShorterThan(..)
>
> English is not my primary language so I don't know which of these
> aliases would be better. Given
On Wed, 9 Jun 2021 15:41:59 GMT, Patrick Concannon
wrote:
> Hi,
>
> Could someone please review my code for updating the code in the `java.time`
> packages to make use of the switch expressions?
>
> Kind regards,
> Patrick
My biggest comment is the spaces used to align, which I strongly
On Wed, 12 May 2021 at 18:41, Roger Riggs wrote:
> Will you be posting a PR for the implementation?
> It is frequently helpful to evaluate the CSR and the implementation
> concurrently.
PR: https://github.com/openjdk/jdk/pull/4016
Issue: https://bugs.openjdk.java.net/browse/JDK-8266846
CSR:
On Sat, 15 May 2021 21:32:54 GMT, Ralph Goers
wrote:
>> 8266846: Add java.time.InstantSource
>
> Can you possibly find a way that this can be used in a garbage free manner?
> Providing a MutableInstant interface that allows the Instant object to be
> provided and have its values set by a
On Thu, 13 May 2021 20:52:33 GMT, Stephen Colebourne
wrote:
> 8266846: Add java.time.InstantSource
It would good to get confirmation in the review from @dholmes-ora or Mark
Kralj-Taylor that my changes to the precise system clock are correct.
Specifically, I moved the code from insta
On Sat, 15 May 2021 20:53:28 GMT, Istvan Neuwirth
wrote:
>> 8266846: Add java.time.InstantSource
>
> src/java.base/share/classes/java/time/InstantSource.java line 93:
>
>> 91: * @since 17
>> 92: */
>> 93: public interface InstantSource {
>
> Should not we add `@FunctionalInterface`? I can
On Sun, 16 May 2021 07:39:21 GMT, Peter Levart wrote:
>> Stephen Colebourne has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8266846: Add java.time.InstantSource
>
> src/java.base/share/classes/java/time/
> 8266846: Add java.time.InstantSource
Stephen Colebourne has updated the pull request incrementally with one
additional commit since the last revision:
8266846: Add java.time.InstantSource
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/4016/files
- new: ht
On Tue, 18 May 2021 21:04:18 GMT, Naoto Sato wrote:
>> Stephen Colebourne has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8266846: Add java.time.InstantSource
>
> test/jdk/java/time/test/java/time/
This is a proposal to add a new interface to java.time.*
public interface TimeSource {
public static TimeSource system() { ... }
public abstract Instant instant();
public default long millis() {
return instant().toEpochMilli();
}
public default Clock withZone(ZoneId
> 8266846: Add java.time.InstantSource
Stephen Colebourne has updated the pull request incrementally with one
additional commit since the last revision:
8266846: Add java.time.InstantSource
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/4016/files
- new: ht
On Mon, 17 May 2021 14:30:20 GMT, Roger Riggs wrote:
>> Stephen Colebourne has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8266846: Add java.time.InstantSource
>
> src/java.base/share/classes/java/time/
On Thu, 13 May 2021 20:52:33 GMT, Stephen Colebourne
wrote:
> 8266846: Add java.time.InstantSource
FWIW, if there is a need to access `VM.getNanoTimeAdjustment(localOffset)` then
that should be a separate issue. I don't personally think it would be approved
given Valhalla is com
On Mon, 17 May 2021 14:13:06 GMT, Roger Riggs wrote:
>> 8266846: Add java.time.InstantSource
>
> src/java.base/share/classes/java/time/InstantSource.java line 165:
>
>> 163: */
>> 164: static InstantSource fixed(Instant fixedInstant) {
>> 165: return Clock.fixed(fixedInstant,
On Mon, 17 May 2021 14:04:24 GMT, Roger Riggs wrote:
>> 8266846: Add java.time.InstantSource
>
> src/java.base/share/classes/java/time/InstantSource.java line 36:
>
>> 34: * Instances of this interface are used to find the current instant.
>> 35: * As such, an {@code InstantSource} can be
On Fri, 14 May 2021 07:19:03 GMT, Anthony Vanelverdinghe
wrote:
>> 8266846: Add java.time.InstantSource
>
> src/java.base/share/classes/java/time/Clock.java line 513:
>
>> 511: * {@link System#currentTimeMillis()} or equivalent.
>> 512: */
>> 513: static final class
8266846: Add java.time.InstantSource
-
Commit messages:
- 8266846: Add java.time.InstantSource
- 8266846: Add java.time.InstantSource
Changes: https://git.openjdk.java.net/jdk/pull/4016/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4016=00
Issue:
> 8266846: Add java.time.InstantSource
Stephen Colebourne has updated the pull request incrementally with one
additional commit since the last revision:
8266846: Add java.time.InstantSource
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/4016/files
- new: ht
On Tue, 18 May 2021 23:18:42 GMT, Stephen Colebourne
wrote:
>> 8266846: Add java.time.InstantSource
>
> Stephen Colebourne has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8266846: Add java.time.InstantSource
I've mad
Hi all,
Is there anything I need to do to progress the CSR and/or PR?
thanks
Stephen
On Thu, 13 May 2021 at 22:05, Stephen Colebourne wrote:
>
> On Wed, 12 May 2021 at 18:41, Roger Riggs wrote:
> > Will you be posting a PR for the implementation?
> > It is frequently helpful t
> 8266846: Add java.time.InstantSource
Stephen Colebourne has updated the pull request incrementally with one
additional commit since the last revision:
8266846: Add java.time.InstantSource
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/4016/files
- new: ht
On Thu, 13 May 2021 20:52:33 GMT, Stephen Colebourne
wrote:
> 8266846: Add java.time.InstantSource
This pull request has now been integrated.
Changeset: 6c838c56
Author: Stephen Colebourne
Committer: Roger Riggs
URL:
https://git.openjdk.java.net/jdk/com
> 8266846: Add java.time.InstantSource
Stephen Colebourne has updated the pull request incrementally with one
additional commit since the last revision:
8266846: Add java.time.InstantSource
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/4016/files
- new: ht
On Fri, 30 Apr 2021 at 19:50, Stuart Marks wrote:
> You're asking for something that's somewhat different, which you called the
> "find
> the first element when there is only one" problem. Here, there's a
> precondition that
> the collection have a single element. (It's not clear to me what
On Wed, 21 Apr 2021 at 18:39, Stuart Marks wrote:
> The value being provided here is that the ReversibleCollection interface
> provides a
> context within which specs no longer need to hedge about "if the collection
> has an
> ordering". APIs that produce or consume ReversibleCollection no
On Thu, 22 Apr 2021 at 13:58, Remi Forax wrote:
> I would like to preserve the invariant that, when calling a method on a
> Collection/iterator, an UnsupportedOperationException only occurs when trying
> to mutate that collection.
> If we are ok with that, this means that addFirst can not be a
On Fri, 23 Apr 2021 at 23:07, Brian Goetz wrote:
> >> Is there a compelling example of where this would be used by clients?
> > Here are some examples:
> > https://stackoverflow.com/questions/10988634/java-global-isempty-method
> Without passing judgment on the sort of dynamically typed programs
On Fri, 23 Apr 2021 at 17:08, Brian Goetz wrote:
> This has come up before. For example, during an early iteration of the
> Stream design, before parallelism entered the picture. The first
> scrawled-on-a-napkin prototype for streams was based on Iterator, and it took
> about a minute to
On Tue, 30 Mar 2021 at 22:02, Maurizio Cimadamore
wrote:
> There are also other interesting types to be explored in that domain,
> such as Long128, LongDouble (extended precision float) and HalfFloats.
Perhaps it would be beneficial to have a GitHub repo where designs for
these could be fleshed
On Fri, 16 Apr 2021 at 18:41, Stuart Marks wrote:
> This is a proposal to add a ReversibleCollection interface to the Collections
> Framework. I'm looking for comments on overall design before I work on
> detailed
> specifications and tests. Please send such comments as replies on this email
>
On Wed, 21 Apr 2021 11:06:16 GMT, Patrick Concannon
wrote:
>> Hi,
>>
>> Could someone please review my code for updating the code in the `java.time`
>> package to make use of the `instanceof` pattern variable?
>>
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request
On Fri, 23 Apr 2021 at 07:33, Stuart Marks wrote:
> On 4/22/21 8:36 AM, Stephen Colebourne wrote:
> Having these methods on Collection could lead to a situation where calling
> addFirst
> and then getFirst might result in getFirst returning a different element from
> wh
Hi all,
While a discussion on ReversibleCollection is going on, I'd like to
raise the interface I've always found most missing from the framework
- Sized
public interface Sized {
int size();
default boolean isEmpty() {
return size() == 0;
}
default boolean isNotEmpty() {
On Mon, 23 Aug 2021 16:42:03 GMT, Naoto Sato wrote:
> Please review the fix to the subject issue. When instant seconds and zone
> co-exist in parsed data, instant seconds was not resolved correctly from them.
LGTM
-
Marked as reviewed by scolebourne (Author).
PR:
On Wed, 8 Sep 2021 00:36:29 GMT, Naoto Sato wrote:
>> Please review the fix to the issue. Avoiding overflow by not calling
>> nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference
>> in nano unit.
>
> Naoto Sato has updated the pull request incrementally with one
On Wed, 8 Sep 2021 00:36:29 GMT, Naoto Sato wrote:
>> Please review the fix to the issue. Avoiding overflow by not calling
>> nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference
>> in nano unit.
>
> Naoto Sato has updated the pull request incrementally with one
On Sun, 26 Sept 2021 at 10:29, Tagir Valeev wrote:
> List list =
> Files.list(Path.of("/etc")).map(Path::getFileName).consumeAndClose(Stream::toList);
>
> What do you think?
I fully support this. We have our own utility to do this kind of
thing, as bugs with `Files` are common:
On Tue, 9 Nov 2021 22:29:12 GMT, Naoto Sato wrote:
> Simple doc clarification where the `toString()` output only conforms to ISO
> 8601 if the seconds in the offset are zero.
Marked as reviewed by scolebourne (Author).
-
PR: https://git.openjdk.java.net/jdk/pull/6321
On Wed, 24 Nov 2021 23:25:22 GMT, Naoto Sato wrote:
>> This fix intends to honor the type (std/dst/generic) of parsed zone name for
>> selecting the offset at the overlap. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with two additional
>
On Mon, 1 Nov 2021 13:04:20 GMT, Claes Redestad wrote:
> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
> formatters are less efficient for some common patterns than custom formatters
> in apache-commons and log4j. This patch reduces the gap, without having
>
On Mon, 1 Nov 2021 22:35:58 GMT, Claes Redestad wrote:
>> The commentary on this line could probably be improved, but this is in a
>> private printer-parser that will only be used for NANO_OF_SECOND and not any
>> arbitrary `TemporalField` (see line 704), thus I fail to see how this
>>
On Wed, 3 Nov 2021 22:55:23 GMT, Claes Redestad wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove accidentally committed experimental @Stable (no effect on micros)
>
> Thanks, Naoto!
@cl4es For
On Tue, 2 Nov 2021 11:03:02 GMT, Claes Redestad wrote:
>> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
>> formatters are less efficient for some common patterns than custom
>> formatters in apache-commons and log4j. This patch reduces the gap, without
>> having
On Wed, 3 Nov 2021 13:14:42 GMT, Claes Redestad wrote:
>> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
>> formatters are less efficient for some common patterns than custom
>> formatters in apache-commons and log4j. This patch reduces the gap, without
>> having
On Mon, 29 Nov 2021 17:41:34 GMT, Naoto Sato wrote:
>> This fix intends to honor the type (std/dst/generic) of parsed zone name for
>> selecting the offset at the overlap. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional
>
On Fri, 23 Jul 2021 17:27:27 GMT, Naoto Sato wrote:
> Please review this PR to introduce `java.time.Duration.isPositive()` method.
> A CSR is also drafted.
Marked as reviewed by scolebourne (Author).
src/java.base/share/classes/java/time/Duration.java line 596:
> 594: */
> 595:
On Fri, 4 Mar 2022 21:17:50 GMT, Jim Laskey wrote:
>> Several attempts have been made to improve Formatter's numeric performance
>> by caching the current Locale zero. Such fixes, however, ignore the real
>> issue, which is the slowness of fetching DecimalFormatSymbols. By directly
>> caching
On Fri, 4 Mar 2022 23:05:56 GMT, Naoto Sato wrote:
>> Supporting `IsoFields` temporal fields in chronologies that are similar to
>> ISO chronology. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last
On Fri, 25 Feb 2022 19:02:55 GMT, Naoto Sato wrote:
> Refactoring `java.time.ZoneId` class to be a sealed class. A CSR has also
> been drafted.
Marked as reviewed by scolebourne (Author).
-
PR: https://git.openjdk.java.net/jdk/pull/7625
On Mon, 28 Feb 2022 23:17:57 GMT, Naoto Sato wrote:
> Fixing the definition and implementation of the pattern symbol `F`. Although
> it is an incompatible change, I believe it is worth the fix. For that, a CSR
> has been drafted.
Although there is incompatibility, I believe a fix is the
On Fri, 25 Mar 2022 14:35:46 GMT, Claes Redestad wrote:
>> Richard Startin prompted me to have a look at a case where java.time
>> underperforms relative to joda time
>> (https://twitter.com/richardstartin/status/1506975932271190017).
>>
>> It seems the java.time test of his suffer from
On Fri, 25 Mar 2022 15:16:42 GMT, Claes Redestad wrote:
>> Richard Startin prompted me to have a look at a case where java.time
>> underperforms relative to joda time
>> (https://twitter.com/richardstartin/status/1506975932271190017).
>>
>> It seems the java.time test of his suffer from
On Wed, 30 Mar 2022 16:46:40 GMT, Naoto Sato wrote:
> Fixes test failures caused by depending on the default locale. Specifying
> explicit `Locale.US` will do.
Marked as reviewed by scolebourne (Author).
-
PR: https://git.openjdk.java.net/jdk/pull/8045
On Wed, 30 Mar 2022 12:06:39 GMT, Claes Redestad wrote:
> A few integer divisions and multiplications can be replaced with test +
> addition, leading to a decent speed-up on java.time microbenchmarks such as
> `GetYearBench`. Numbers from my local x86 workstation, seeing similar
> speed-up on
On Thu, 27 Jan 2022 at 19:23, Naoto Sato wrote:
> Now come to think of it, I came up with the draft based on `ofPattern()`
> methods. One of them is a overload method that takes a Locale argument.
> Why is it so?
There is a case for the Locale on the static method (as a convenience,
and to
Hi,
This would be a useful addition. Some comments:
There is no need for the method overload that takes Locale. The other
similar methods all operate using the locale of the formatter, and
have this Javadoc:
* The locale is determined from the formatter. The formatter
returned directly by
On Fri, 29 Apr 2022 06:31:22 GMT, Andrey Turbanov wrote:
> `Map.containsKey` call is sometimes unnecessary, when it's known that Map
> doesn't contain `null` values.
> Instead we can just use Map.get and compare result with `null`.
> I found one of such place, where Map.containsKey calls could
On Wed, 4 May 2022 20:27:04 GMT, lennartfricke wrote:
> Provide micro-benchmark for comparison
Seems reasonable to me. plus(long, long) already has this optimisation.
-
Marked as reviewed by scolebourne (Author).
PR: https://git.openjdk.java.net/jdk/pull/8542
On Tue, 10 May 2022 17:43:07 GMT, Naoto Sato wrote:
>> test/jdk/java/util/TimeZone/ZoneOffsetRoundTripTest.java line 43:
>>
>>> 41: private Object[][] testZoneOffsets() {
>>> 42: return new Object[][] {
>>> 43: {ZoneId.of("Z"), 0},
>>
>> I know, `ZoneId.of()` should
On Wed, 11 May 2022 20:04:39 GMT, Naoto Sato wrote:
>> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support
>> second-level resolution, enabling round trips with `java.time.ZoneOffset`s.
>> Corresponding CSR is also being drafted.
>
> Naoto Sato has updated the pull
401 - 483 of 483 matches
Mail list logo
