[GitHub] [commons-email] fak98 commented on pull request #133: Migrate to jakarta package namespace ( and commons-email2 )
fak98 commented on PR #133: URL: https://github.com/apache/commons-email/pull/133#issuecomment-1657775632 +1 for this PR too. We need this as it's blocking us from upgrading to Jetty 11. How does this get progressed? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (NET-718) "Unsupported or unrecognized SSL message" for FTPS via proxy
[
https://issues.apache.org/jira/browse/NET-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17749021#comment-17749021
]
Gary D. Gregory commented on NET-718:
-
See also [https://github.com/apache/commons-net/pull/154], a reproducer that
needs to be converted into a test.
> "Unsupported or unrecognized SSL message" for FTPS via proxy
>
>
> Key: NET-718
> URL: https://issues.apache.org/jira/browse/NET-718
> Project: Commons Net
> Issue Type: Bug
>Affects Versions: 3.9.0
>Reporter: Sebastian Alfers
>Priority: Major
>
> After bumping from commons-net 3.8 to 3.9, we started to see this error.
> I happens only when using FTPS via a proxy, and it is likely that this change
> may have introduced.
>
> Any recommendation how to bring back the pre-3.9 behavior? This is the full
> stacktrace:
> {code:java}
> Start of log messages of test that failed with assertion failed:
> fishForMessage(OnNext(_) or OnComplete) found unexpected message
> OnError(javax.net.ssl.SSLException: Unsupported or unrecognized SSL message
> at
> java.base/sun.security.ssl.SSLSocketInputRecord.handleUnknownRecord(SSLSocketInputRecord.java:451)
> at
> java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:175)
> at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:111)
> at
> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1505)
> at
> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1420)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:455)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:426)
> at
> org.apache.commons.net.ftp.FTPSClient.openDataConnection(FTPSClient.java:278)
> at
> org.apache.commons.net.ftp.FTPClient._retrieveFileStream(FTPClient.java:915)
> at
> org.apache.commons.net.ftp.FTPClient.retrieveFileStream(FTPClient.java:2841)
> at
> akka.stream.alpakka.ftp.impl.CommonFtpOperations.$anonfun$retrieveFileInputStream$1(CommonFtpOperations.scala:71)
> at scala.util.Try$.apply(Try.scala:210) {code}
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [commons-geometry] darkma773r commented on pull request #218: Refactor hull
darkma773r commented on PR #218: URL: https://github.com/apache/commons-geometry/pull/218#issuecomment-1657416998 This looks great! Thank you, @agoss94! I think the only things to address are the two points made above (toString and caching the quadrilateral) and the code coverage. There are several if statement branches in `ConvexHull2D` that are not hit by the tests, which makes me think that either the tests are not sufficiently hitting all of the edge cases or those statements are not needed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-geometry] darkma773r commented on a diff in pull request #218: Refactor hull
darkma773r commented on code in PR #218:
URL: https://github.com/apache/commons-geometry/pull/218#discussion_r1278704664
##
commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/twod/hull/ConvexHull2D.java:
##
@@ -0,0 +1,475 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.commons.geometry.euclidean.twod.hull;
+
+import java.util.ArrayList;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.Iterator;
+import java.util.List;
+
+import org.apache.commons.geometry.core.ConvexHull;
+import org.apache.commons.geometry.euclidean.EuclideanCollections;
+import org.apache.commons.geometry.euclidean.twod.ConvexArea;
+import org.apache.commons.geometry.euclidean.twod.Lines;
+import org.apache.commons.geometry.euclidean.twod.Vector2D;
+import org.apache.commons.geometry.euclidean.twod.path.LinePath;
+import org.apache.commons.numbers.core.Precision;
+
+/**
+ * This class represents a convex hull in two-dimensional Euclidean space.
+ */
+public final class ConvexHull2D implements ConvexHull {
+
+/** Vertices for the convex hull, in order. */
+private final List vertices;
+
+/** Polyline path for the convex hull. */
+private final LinePath path;
+
+/** Simple constructor; no validation is performed.
+ * @param vertices the vertices of the convex hull; callers are
responsible for ensuring that
+ * the given vertices are in order, unique, and define a convex hull.
+ * @param precision precision context used to compare floating point
numbers
+ */
+ConvexHull2D(final Collection vertices, final
Precision.DoubleEquivalence precision) {
+this.vertices = Collections.unmodifiableList(new
ArrayList<>(vertices));
+this.path = buildHullPath(vertices, precision);
+}
+
+/** {@inheritDoc} */
+@Override
+public List getVertices() {
+return vertices;
+}
+
+/** Get a path defining the convex hull. The path will contain
+ *
+ * zero segments if the hull consists of only a single point,
+ * one segment if the hull consists of two points,
+ * three or more segments defining a closed loop if the hull
consists of more than
+ * two non-collinear points.
+ *
+ * @return polyline path defining the convex hull
+ */
+public LinePath getPath() {
+return path;
+}
+
+/** {@inheritDoc} */
+@Override
+public ConvexArea getRegion() {
+return path.isClosed() ?
+ConvexArea.convexPolygonFromPath(path) :
+null;
+}
+
+/** {@inheritDoc} */
+@Override
+public String toString() {
+final StringBuilder sb = new StringBuilder();
+sb.append(getClass().getSimpleName())
+.append("[vertices= ")
+.append(getVertices())
Review Comment:
That's probably a good idea. If we do this here, we should update (in
another ticket) other classes that currently produce arbitrarily large
`toString` representations, like `LinePath`. They should be consistent in the
number of vertices printed before truncation.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-geometry] darkma773r commented on a diff in pull request #218: Refactor hull
darkma773r commented on code in PR #218:
URL: https://github.com/apache/commons-geometry/pull/218#discussion_r1278700931
##
commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/twod/hull/ConvexHull2D.java:
##
@@ -0,0 +1,475 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.commons.geometry.euclidean.twod.hull;
+
+import java.util.ArrayList;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.Iterator;
+import java.util.List;
+
+import org.apache.commons.geometry.core.ConvexHull;
+import org.apache.commons.geometry.euclidean.EuclideanCollections;
+import org.apache.commons.geometry.euclidean.twod.ConvexArea;
+import org.apache.commons.geometry.euclidean.twod.Lines;
+import org.apache.commons.geometry.euclidean.twod.Vector2D;
+import org.apache.commons.geometry.euclidean.twod.path.LinePath;
+import org.apache.commons.numbers.core.Precision;
+
+/**
+ * This class represents a convex hull in two-dimensional Euclidean space.
+ */
+public final class ConvexHull2D implements ConvexHull {
+
+/** Vertices for the convex hull, in order. */
+private final List vertices;
+
+/** Polyline path for the convex hull. */
+private final LinePath path;
+
+/** Simple constructor; no validation is performed.
+ * @param vertices the vertices of the convex hull; callers are
responsible for ensuring that
+ * the given vertices are in order, unique, and define a convex hull.
+ * @param precision precision context used to compare floating point
numbers
+ */
+ConvexHull2D(final Collection vertices, final
Precision.DoubleEquivalence precision) {
+this.vertices = Collections.unmodifiableList(new
ArrayList<>(vertices));
+this.path = buildHullPath(vertices, precision);
+}
+
+/** {@inheritDoc} */
+@Override
+public List getVertices() {
+return vertices;
+}
+
+/** Get a path defining the convex hull. The path will contain
+ *
+ * zero segments if the hull consists of only a single point,
+ * one segment if the hull consists of two points,
+ * three or more segments defining a closed loop if the hull
consists of more than
+ * two non-collinear points.
+ *
+ * @return polyline path defining the convex hull
+ */
+public LinePath getPath() {
+return path;
+}
+
+/** {@inheritDoc} */
+@Override
+public ConvexArea getRegion() {
+return path.isClosed() ?
+ConvexArea.convexPolygonFromPath(path) :
+null;
+}
+
+/** {@inheritDoc} */
+@Override
+public String toString() {
+final StringBuilder sb = new StringBuilder();
+sb.append(getClass().getSimpleName())
+.append("[vertices= ")
+.append(getVertices())
+.append(']');
+
+return sb.toString();
+}
+
+/** Build a polyline representing the path for a convex hull.
+ * @param vertices convex hull vertices
+ * @param precision precision context used to compare floating point values
+ * @return path for the convex hull defined by the given vertices
+ */
+private static LinePath buildHullPath(final Collection vertices,
+final Precision.DoubleEquivalence precision) {
+if (vertices.size() < 2) {
+return LinePath.empty();
+}
+
+final boolean closeLoop = vertices.size() > 2;
+
+return LinePath.builder(precision)
+.appendVertices(vertices)
+.build(closeLoop);
+}
+
+/** Class used to build convex hulls. The builder is based on the
Akl-Toussaint
+ * heuristic to construct the hull. The heuristic is based on the idea of a
+ * convex quadrilateral, which is formed by four points with the lowest and
+ * highest x / y coordinates. Any point that lies inside this
quadrilateral can
+ * not be part of the convex hull and can thus be safely discarded before
+ * generating the convex hull itself.
+ *
+ * The complexity of the operation is O(n), and may greatly improve the
time it
+ * takes to construct the convex hull afterwa
[jira] [Commented] (IMAGING-356) TIFF reading extremely slow in version 1.0-SNAPSHOT
[ https://issues.apache.org/jira/browse/IMAGING-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17748957#comment-17748957 ] Gary Lucas commented on IMAGING-356: That's certainly feasible within the structure of the existing code. In any case, an exception would be an exception, but at least we could make the code throw an exception that provided slightly more information to the developer using the API (something like "your image file has to be broken because otherwise this stuff would work"). > TIFF reading extremely slow in version 1.0-SNAPSHOT > --- > > Key: IMAGING-356 > URL: https://issues.apache.org/jira/browse/IMAGING-356 > Project: Commons Imaging > Issue Type: Bug > Components: Format: TIFF >Affects Versions: 1.0 >Reporter: Gary Lucas >Priority: Major > Attachments: image-2023-07-04-08-52-36-535.png > > > I am using the latest code from github (1.0-SNAPSHOT downloaded from github > of June 2023) to read a 300 megabyte TIFF file. Version 1.0-alpha3 required > 673 milliseconds to read that file. The new code requires upward of 15 > minutes. Clearly something got broken since the last release. > The TIFF file is a 1x1 pixel 4 byte image format organized in strips. > The bottleneck appears to occur in the TiffReader getTiffRawImageData method > which reads raw data from the file in preparation of creating a BufferedImage > object. > I suspect that there may be a general slowness of file access. In debugging, > even reading the initial metadata (22 TIFF tags) took a couple of seconds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NET-718) "Unsupported or unrecognized SSL message" for FTPS via proxy
[
https://issues.apache.org/jira/browse/NET-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17748934#comment-17748934
]
PJ Fanning commented on NET-718:
Presumably the change in [https://github.com/apache/commons-net/pull/90] fixes
some issue for some users but breaks FTPS proxy for other users. Maybe one
solution is to introduce a new setting that allows users to turn off the code
in
https://github.com/apache/commons-net/blob/master/src/main/java/org/apache/commons/net/ftp/FTPSClient.java#L794-L796
> "Unsupported or unrecognized SSL message" for FTPS via proxy
>
>
> Key: NET-718
> URL: https://issues.apache.org/jira/browse/NET-718
> Project: Commons Net
> Issue Type: Bug
>Affects Versions: 3.9.0
>Reporter: Sebastian Alfers
>Priority: Major
>
> After bumping from commons-net 3.8 to 3.9, we started to see this error.
> I happens only when using FTPS via a proxy, and it is likely that this change
> may have introduced.
>
> Any recommendation how to bring back the pre-3.9 behavior? This is the full
> stacktrace:
> {code:java}
> Start of log messages of test that failed with assertion failed:
> fishForMessage(OnNext(_) or OnComplete) found unexpected message
> OnError(javax.net.ssl.SSLException: Unsupported or unrecognized SSL message
> at
> java.base/sun.security.ssl.SSLSocketInputRecord.handleUnknownRecord(SSLSocketInputRecord.java:451)
> at
> java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:175)
> at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:111)
> at
> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1505)
> at
> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1420)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:455)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:426)
> at
> org.apache.commons.net.ftp.FTPSClient.openDataConnection(FTPSClient.java:278)
> at
> org.apache.commons.net.ftp.FTPClient._retrieveFileStream(FTPClient.java:915)
> at
> org.apache.commons.net.ftp.FTPClient.retrieveFileStream(FTPClient.java:2841)
> at
> akka.stream.alpakka.ftp.impl.CommonFtpOperations.$anonfun$retrieveFileInputStream$1(CommonFtpOperations.scala:71)
> at scala.util.Try$.apply(Try.scala:210) {code}
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [commons-io] garydgregory merged pull request #470: Bump actions/setup-java from 3.11.0 to 3.12.0
garydgregory merged PR #470: URL: https://github.com/apache/commons-io/pull/470 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (NET-718) "Unsupported or unrecognized SSL message" for FTPS via proxy
[
https://issues.apache.org/jira/browse/NET-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17748931#comment-17748931
]
PJ Fanning commented on NET-718:
We're seeing this in Apache Pekko FTP connector too. Upgrading from commons-net
3.8.0 to 3.9.0 breaks a FTPS proxy test case - with same exception shown in
description.
> "Unsupported or unrecognized SSL message" for FTPS via proxy
>
>
> Key: NET-718
> URL: https://issues.apache.org/jira/browse/NET-718
> Project: Commons Net
> Issue Type: Bug
>Affects Versions: 3.9.0
>Reporter: Sebastian Alfers
>Priority: Major
>
> After bumping from commons-net 3.8 to 3.9, we started to see this error.
> I happens only when using FTPS via a proxy, and it is likely that this change
> may have introduced.
>
> Any recommendation how to bring back the pre-3.9 behavior? This is the full
> stacktrace:
> {code:java}
> Start of log messages of test that failed with assertion failed:
> fishForMessage(OnNext(_) or OnComplete) found unexpected message
> OnError(javax.net.ssl.SSLException: Unsupported or unrecognized SSL message
> at
> java.base/sun.security.ssl.SSLSocketInputRecord.handleUnknownRecord(SSLSocketInputRecord.java:451)
> at
> java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:175)
> at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:111)
> at
> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1505)
> at
> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1420)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:455)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:426)
> at
> org.apache.commons.net.ftp.FTPSClient.openDataConnection(FTPSClient.java:278)
> at
> org.apache.commons.net.ftp.FTPClient._retrieveFileStream(FTPClient.java:915)
> at
> org.apache.commons.net.ftp.FTPClient.retrieveFileStream(FTPClient.java:2841)
> at
> akka.stream.alpakka.ftp.impl.CommonFtpOperations.$anonfun$retrieveFileInputStream$1(CommonFtpOperations.scala:71)
> at scala.util.Try$.apply(Try.scala:210) {code}
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [commons-collections] Claudenw commented on a diff in pull request #406: COLLECTIONS-844 - allow counting Bloom filters with cell size other than Integer.SIZE
Claudenw commented on code in PR #406:
URL:
https://github.com/apache/commons-collections/pull/406#discussion_r1278563011
##
src/main/java/org/apache/commons/collections4/bloomfilter/CountingBloomFilter.java:
##
@@ -121,7 +186,7 @@ default boolean merge(final Hasher hasher) {
/**
* Merges the specified index producer into this Bloom filter.
*
- * Specifically: all counts for the indexes identified by the {@code
indexProducer} will be incremented by 1.
+ * Specifically: all cells for the indexes identified by the {@code
indexProducer} will be incremented by 1.
Review Comment:
Should all be fixed and ready to go now.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (IMAGING-356) TIFF reading extremely slow in version 1.0-SNAPSHOT
[
https://issues.apache.org/jira/browse/IMAGING-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17748918#comment-17748918
]
Gilles Sadowski commented on IMAGING-356:
-
{quote}{{ArrayIndexOutOfBounds}} [...] data[ y * width + x] = argb;
{quote}
Does this occur in a loop that updates all the "data" array? [Sorry, I didn't
follow the whole discussion.]
If so, the loop could be enclosed in a try/catch block so that the propagated
exception could convey that corruption was detected by the library.
> TIFF reading extremely slow in version 1.0-SNAPSHOT
> ---
>
> Key: IMAGING-356
> URL: https://issues.apache.org/jira/browse/IMAGING-356
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: TIFF
>Affects Versions: 1.0
>Reporter: Gary Lucas
>Priority: Major
> Attachments: image-2023-07-04-08-52-36-535.png
>
>
> I am using the latest code from github (1.0-SNAPSHOT downloaded from github
> of June 2023) to read a 300 megabyte TIFF file. Version 1.0-alpha3 required
> 673 milliseconds to read that file. The new code requires upward of 15
> minutes. Clearly something got broken since the last release.
> The TIFF file is a 1x1 pixel 4 byte image format organized in strips.
> The bottleneck appears to occur in the TiffReader getTiffRawImageData method
> which reads raw data from the file in preparation of creating a BufferedImage
> object.
> I suspect that there may be a general slowness of file access. In debugging,
> even reading the initial metadata (22 TIFF tags) took a couple of seconds.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LANG-1704) ImmutablePair and ImmutableTriple implementation don't match final in Javadoc
[
https://issues.apache.org/jira/browse/LANG-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17748915#comment-17748915
]
Gilles Sadowski commented on LANG-1704:
---
bq. That's never going to be true ...
IIUC, the OP said that the change broke his use-case. Maybe we need more
details on this but I can imagine that subverting the (strong) typing system is
not a good idea (passing an "ImmutablePair" that could not be immutable
also breaks the caller's expectation).
That functionality may have been broken, independently of the change being
binary and/or source compatible.
Immutable data-structures much simplify usage, with some trade-off (like no
support for inheritance).
What was the intended functionality?
Why the class was previously "final"?
Depending on the answer, removing "final" was wrong, or name of the class was
ill-chosen.
{quote}
* Allow typed subclasses, for example, MyCustomPair extends ImmutablePair
* Allow inline subclasses, for example, new ImmutablePair(foo, bar) \{ some
overrides } (handy when writing tests).
{quote}
AFAIK, this can be achieved through composition (more lines of code, sure)
increasing encapsulation, and thus safety. The latter is reduced when
increasing visibility; doing so for the sake of unit tests is not good.
> ImmutablePair and ImmutableTriple implementation don't match final in Javadoc
> -
>
> Key: LANG-1704
> URL: https://issues.apache.org/jira/browse/LANG-1704
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.tuple.*
>Affects Versions: 3.13.0
>Reporter: Dan Ziemba
>Priority: Minor
> Fix For: 3.13.1
>
>
> As of commons-lang3 3.13.0, the ImmutablePair and ImmutableTriple classes are
> no longer final, even though their javadocs claim that they are. This is a
> problem because you can now subclass those and, for example, make an
> effectively mutable object that could be passed to a method with a parameter
> of type ImmutablePair.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [commons-email] times29 commented on pull request #133: Migrate to jakarta package namespace ( and commons-email2 )
times29 commented on PR #133: URL: https://github.com/apache/commons-email/pull/133#issuecomment-1657062293 +1 for this PR :) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
