For more details, see
https://ci-hadoop.apache.org/job/hadoop-qbt-branch-2.10-java7-linux-x86_64/980/
No changes
ERROR: File 'out/email-report.txt' does not exist
-
To unsubscribe, e-mail:
I would also vote for targeting 3.4 and have a long term version of Java
there.
On Tue, Mar 28, 2023 at 11:52 AM Igor Dvorzhak
wrote:
> +1 to re-focusing on 3.4 branch and upgrading it to Java 11/17, instead of
> making potentially breaking changes to 3.3.
>
> On Tue, Mar 28, 2023 at 11:17 AM
+1 to re-focusing on 3.4 branch and upgrading it to Java 11/17, instead of
making potentially breaking changes to 3.3.
On Tue, Mar 28, 2023 at 11:17 AM Chris Nauroth wrote:
> In theory, I like the idea of setting aside Java 8. Unfortunately, I don't
> know that upgrading within the 3.3 line
In theory, I like the idea of setting aside Java 8. Unfortunately, I don't
know that upgrading within the 3.3 line adheres to our binary compatibility
policy [1]. I don't see specific discussion of the Java version there, but
it states that you should be able to drop in minor upgrades and have
>
> it's already hard to migrate from JDK8 why not retarget JDK17.
>
+1, makes sense to me, sounds like a win-win situation to me, though there
would be some additional issues to chase now :)
-Ayush
On Tue, 28 Mar 2023 at 23:29, Wei-Chiu Chuang wrote:
> My random thoughts. Probably bad
On Mon, Mar 27, 2023 at 20:29 Wei-Chiu Chuang wrote:
> For complex applications such as
> HBase it is almost impossible to achieve true FS agnosticity without proper
> contract tests, as now I am starting to realize.
>
This is absolutely true. HBase jumps through all sorts of painful
reflective
My random thoughts. Probably bad takes:
There are projects experimenting with JDK17 now.
JDK11 active support will end in 6 months. If it's already hard to migrate
from JDK8 why not retarget JDK17.
On Tue, Mar 28, 2023 at 10:30 AM Ayush Saxena wrote:
> I know Jersey upgrade as a blocker. Some
I know Jersey upgrade as a blocker. Some folks were chasing that last year
during 3.3.4 time, I don’t know where it is now, didn’t see then what’s the
problem there but I remember there was some intitial PR which did it for HDFS
atleast, so I never looked beyond that…
I too had jdk-11 in my
well, how about we flip the switch and get on with it.
slf4j seems happy on java11,
side issue, anyone seen test failures on zulu1.8; somehow my test run is
failing and i'm trying to work out whether its a mismatch in command
line/ide jvm versions, or the 3.3.5 JARs have been built with an
IIRC some of the ongoing major dependency upgrades (log4j 1 to 2, jersey 1
to 2 and junit 4 to 5) are blockers for java 11 compile + test stability.
On Tue, Mar 28, 2023 at 4:55 AM Steve Loughran
wrote:
> Now that hadoop 3.3.5 is out, i want to propose something new
>
> we switch branch-3.3
For more details, see
https://ci-hadoop.apache.org/job/hadoop-qbt-trunk-java8-linux-x86_64/1179/
[Mar 27, 2023, 7:59:02 AM] (github) HADOOP-18676. jettison dependency override
in hadoop-common lib (#5513)
[Mar 27, 2023, 11:43:34 AM] (github) HADOOP-18146: ABFS: Added changes for
expect hundred
Now that hadoop 3.3.5 is out, i want to propose something new
we switch branch-3.3 and trunk to being java11 only
1. java 11 has been out for years
2. oracle java 8 is no longer available under "premier support"; you
can't really get upgrades
[
https://issues.apache.org/jira/browse/HDFS-16964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiaoqiao He resolved HDFS-16964.
Fix Version/s: 3.4.0
Hadoop Flags: Reviewed
Resolution: Fixed
> Improve processing of
13 matches
Mail list logo
