Filed HBASE-26793 for making a new hbase-thirdparty release.
Then will put the PR for HBASE-25465.
Thanks.
张铎(Duo Zhang) 于2022年3月2日周三 11:19写道：
> Good news, with HBASE-26781 in place[1], I successfully built hbase with
> java 11 --release 8. Of course I need to modify the hbase main code a
Good news, with HBASE-26781 in place[1], I successfully built hbase with
java 11 --release 8. Of course I need to modify the hbase main code a bit,
and also make use of netty's PlatformDependent for processing
DirectByteBuffer.
1. https://github.com/apache/hbase-thirdparty/pull/79
张铎(Duo Zhang)
So after HBASE-26773, we still have another problem that we can not
use sun.nio.ch.DirectBuffer. The main usage is to get the address.
Let me provide a new util method in the hbase-unsafe module.
Andrew Purtell 于2022年2月26日周六 13:58写道：
> That sounds good, looking forward to it. Please let me
That sounds good, looking forward to it. Please let me know if you want help.
> On Feb 25, 2022, at 9:56 PM, 张铎 wrote:
>
> Filed HBASE-26773 and tried, the result is not very good. Netty's
> PlatformDependent can not meet all the requirements.
>
> So now I prefer we have a new
Filed HBASE-26773 and tried, the result is not very good. Netty's
PlatformDependent can not meet all the requirements.
So now I prefer we have a new hbase-thirdparty-unsafe module to provide the
Unsafe ability without exposing sun.misc.Unsafe directly.
Will give it a try.
Thanks.
Andrew
Ok, a bridge in one place would minimize the risk.
On Wed, Feb 23, 2022 at 6:07 PM 张铎(Duo Zhang) wrote:
> I think this is a reasonable concern, we could do this on our own.
>
> But checking the commit history of PlatformDependent[1], the API is pretty
> stable, so I think the risk of hitting a
I think this is a reasonable concern, we could do this on our own.
But checking the commit history of PlatformDependent[1], the API is pretty
stable, so I think the risk of hitting a security issue but we can not
upgrade due to API conflicts is very low. And if a security issue requires
big
We often upgrade netty after there is a CVE announcement. This produces a
pressure to upgrade in production. Use of an internal API is not a good
practice because it can cause friction because of breaking changes when
there is a need to upgrade all of a sudden. This is painful and hopefully
we can
For me, since we shade netty, there will be no conflict with other netty
dependencies, so we can make sure the netty version we used is exactly the
one we shaded in hbase-thirdparty.
If later we want to upgrade netty version in hbase-thirdparty, and it
breaks the api, then we can release a new
Thanks for that. I understand better what you are proposing now. It is
clear that you have thought it through.
So then the only question I have is this: Do you think it is a concern that
Netty's PlatformDependent class is in their "io.netty.util.internal"
package? The 'internal' designation
What I proposed here is for solving the problem…
The problem is that when using —release 8, javac will not export the
jdk.unsupported symbols, so using sun.misc.Unsafe will trigger a compile
error. But at runtime if you export jdk.unsupported you can still use
sun.misc.Unsafe. The related jdk
As Nick discovered ‘—release’ doesn’t work for version 8 anyway.
> On Feb 20, 2022, at 3:47 PM, 张铎 wrote:
>
> I know, with —release 8 ByteBuffer will not be an problem but then
> sun.misc.Unsafe can not be used any more right? So the problem here is how
> to make use of Unsafe with —release
I know, with —release 8 ByteBuffer will not be an problem but then
sun.misc.Unsafe can not be used any more right? So the problem here is how
to make use of Unsafe with —release 8. What I proposed here is that we just
do not use it, then we can make use of —release 8 to address the ByteBuffer
The problem that leads us to consider '--release 8', or what it would
promise if it worked, isn't Unsafe, it is ByteBuffer.
https://www.morling.dev/blog/bytebuffer-and-the-dreaded-nosuchmethoderror/
. Although to your point Netty has ByteBuf...
On Sun, Feb 20, 2022 at 5:23 AM 张铎(Duo Zhang)
Since we have shaded netty, I think we could make use of
netty's PlatformDependent[1] class to avoid referencing Unsafe directly,
then there will be no problem for us to use the '--release 8' option.
If no big concerns, I will file an issue to remove all the sun.misc.Unsafe
references in our code
so we would require a specific patch release of Hadoop as a minimum? It's
messy, but we've certainly done it before.
On Thu, Feb 17, 2022 at 1:31 PM Andrew Purtell wrote:
> On Thu, Feb 17, 2022 at 10:50 AM Steve Loughran wrote:
>
> > j
> > On 2022/02/15 22:27:50 Andrew Purtell wrote:
> >
> > >
On Thu, Feb 17, 2022 at 10:50 AM Steve Loughran wrote:
> j
> On 2022/02/15 22:27:50 Andrew Purtell wrote:
>
> > The primary consideration to my mind is the state of S3A: in what
> version it can be said to be stable and feature complete. I think 3.3 is
> the appropriate code line for that
j
On 2022/02/15 22:27:50 Andrew Purtell wrote:
> The primary consideration to my mind is the state of S3A: in what version it
> can be said to be stable and feature complete. I think 3.3 is the appropriate
> code line for that criteria but perhaps 3.2 could serve as well.
3.3.1. i have not
On 2/16/22 12:24 AM, Sean Busbey wrote:
Regarding the original question, I would be in favor of the proposal. Time
marches on. I assume just to state the obvious that our destination of
minimum LTS would shift from 8 to 11.
Yes, sorry I should have expressly stated JDK11 would become the
I think this could be done by some module tricks, where we build a special
module with -source 8 and -target 8.We have done similar things in the past
to have hadoop1-compat and hadoop2-compact.
Let me have a try.
Sean Busbey 于2022年2月16日周三 13:31写道：
> Unfortunately if we want to keep jdk8
Unfortunately if we want to keep jdk8 working we can't rely on building
with the jdk release target option on newer jdks.
We ran into this recently in HBASE-25465 where a JDK bug came up.
On Tue, Feb 15, 2022 at 8:12 PM 张铎(Duo Zhang) wrote:
> +1 on moving the minimum required java version for
> Regarding the original question, I would be in favor of the proposal. Time
> marches on. I assume just to state the obvious that our destination of
> minimum LTS would shift from 8 to 11.
Yes, sorry I should have expressly stated JDK11 would become the minimum
with some release after HBase 3.
+1 on moving the minimum required java version for compiling HBase to Java
11. But we could still use --release=8 to still support jdk8 at runtime.
Java 8 is still widely used, and I believe this will last for even more
years, as lots of big companies such as RedHat, Microsoft and Amazon are
If we set the minJDK to 11 I believe that will effectively remove jdk8
support, rather than "just" deprecate it.
As we build out more robust testing I would be in favor of running less of
it on deprecated JDKs.
On Tue, Feb 15, 2022, 16:10 Josh Elser wrote:
> Deprecating jdk8 for HBase 3 and
The section in our docs on JDK11 seems out of date. In my experience using Java
11 to run ZooKeeper (3.5), Hadoop HDFS/YARN/MR (2.10 and 3.3), and HBase (2.4)
is a nonissue. These software versions are stable under load. Most recently I
tested scale ingest with 11.0.15+1, hot off the presses so
Deprecating jdk8 for HBase 3 and requiring minJdk=11 seems reasonable to me.
Gotta start pushing the issue somehow.
On 2/15/22 1:47 PM, Sean Busbey wrote:
Hi folks!
It's been some time since we decided to stick to LTS JDK releases as a way
of getting a handle on the JDK treadmill.
What do
Hi folks!
It's been some time since we decided to stick to LTS JDK releases as a way
of getting a handle on the JDK treadmill.
What do folks think about deprecating JDK8? The openjdk8u project is still
going and there are commercial support options at least through 2030.
Deprecating it in HBase
27 matches
Mail list logo
