[
https://issues.apache.org/jira/browse/KAFKA-21284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dejan Stojadinović updated KAFKA-21284:
---------------------------------------
Description:
*Rationale:*
[https://github.com/classgraph/classgraph/releases#release-classgraph-4.8.199]
{quote}*4.8.199 is the last ClassGraph 4.x release. ClassGraph 4.x has reached
end of life:* there will be no further 4.x releases, other than releases that
backport fixes for serious bugs.
Please upgrade to ClassGraph 6, the new mainline release, for JDK 25 and newer.
If your project must still run on JDK 17 to 24, use ClassGraph 5 until it can
move to JDK 25. ClassGraph 5 has the same API and behavior as ClassGraph 6, and
will be kept in sync with it for the near future. Both have a new API: the
porting guide walks through the port from 4.x step by step, and a coding agent
can follow it for you.
{quote}
*Related links:*
* [https://github.com/classgraph/classgraph/releases/tag/classgraph-5.0.0]
*
[https://github.com/classgraph/classgraph/wiki/Porting-ClassGraph-4.x-code-to-ClassGraph-6.x]
{quote}*_Use ClassGraph 6.x wherever you can, i.e. on JDK 25 or newer._* All
legacy code has been removed from 6.x, including the workarounds for older JDKs
and the reflection-based workarounds, so it is the most future-proof version.
ClassGraph 4.x and 5.x are stop-gaps for projects that cannot yet run on a
recent JDK.
*ClassGraph 5.x.* This page describes ClassGraph 6.x, which requires JDK 25 or
newer. {color:#de350b}_ClassGraph 5.x has the same API and the same behavior,
runs on JDK 17 or newer, and is kept in sync with 6.x for critical bug-fix
releases._{color} To port to 5.x, follow this page and read "6.x" as "5.x"
throughout. On JDK 17 to 24, two things behave differently, because the JDK
does: below JDK 22, reading a memory-mapped ByteBuffer after the ScanResult or
Vfs that owns it has been closed takes a SIGSEGV that kills the JVM, rather
than throwing IllegalStateException (files are memory-mapped only on Windows,
so this can only happen there); and on JDK 17 to 23, if you enable the Security
Manager with -Djava.security.manager=allow, ClassGraph does not run its
reflective calls inside AccessController#doPrivileged, so grant the calling
code the permissions ClassGraph needs.
{quote}
was:
*Rationale:*
[https://github.com/classgraph/classgraph/releases#release-classgraph-4.8.199]
{quote}4.8.199 is the last ClassGraph 4.x release. ClassGraph 4.x has reached
end of life: there will be no further 4.x releases, other than releases that
backport fixes for serious bugs.
Please upgrade to ClassGraph 6, the new mainline release, for JDK 25 and newer.
If your project must still run on JDK 17 to 24, use ClassGraph 5 until it can
move to JDK 25. ClassGraph 5 has the same API and behavior as ClassGraph 6, and
will be kept in sync with it for the near future. Both have a new API: the
porting guide walks through the port from 4.x step by step, and a coding agent
can follow it for you.
{quote}
*Related links:*
* [https://github.com/classgraph/classgraph/releases/tag/classgraph-5.0.0]
*
[https://github.com/classgraph/classgraph/wiki/Porting-ClassGraph-4.x-code-to-ClassGraph-6.x]
{quote}*_Use ClassGraph 6.x wherever you can, i.e. on JDK 25 or newer._* All
legacy code has been removed from 6.x, including the workarounds for older JDKs
and the reflection-based workarounds, so it is the most future-proof version.
ClassGraph 4.x and 5.x are stop-gaps for projects that cannot yet run on a
recent JDK.
*ClassGraph 5.x.* This page describes ClassGraph 6.x, which requires JDK 25 or
newer. {color:#de350b}_ClassGraph 5.x has the same API and the same behavior,
runs on JDK 17 or newer, and is kept in sync with 6.x for critical bug-fix
releases._{color} To port to 5.x, follow this page and read "6.x" as "5.x"
throughout. On JDK 17 to 24, two things behave differently, because the JDK
does: below JDK 22, reading a memory-mapped ByteBuffer after the ScanResult or
Vfs that owns it has been closed takes a SIGSEGV that kills the JVM, rather
than throwing IllegalStateException (files are memory-mapped only on Windows,
so this can only happen there); and on JDK 17 to 23, if you enable the Security
Manager with -Djava.security.manager=allow, ClassGraph does not run its
reflective calls inside AccessController#doPrivileged, so grant the calling
code the permissions ClassGraph needs.
{quote}
> Upgrade ClassGraph version from 4 to 5
> --------------------------------------
>
> Key: KAFKA-21284
> URL: https://issues.apache.org/jira/browse/KAFKA-21284
> Project: Kafka
> Issue Type: Task
> Reporter: Dejan Stojadinović
> Assignee: Dejan Stojadinović
> Priority: Minor
>
> *Rationale:*
> [https://github.com/classgraph/classgraph/releases#release-classgraph-4.8.199]
> {quote}*4.8.199 is the last ClassGraph 4.x release. ClassGraph 4.x has
> reached end of life:* there will be no further 4.x releases, other than
> releases that backport fixes for serious bugs.
> Please upgrade to ClassGraph 6, the new mainline release, for JDK 25 and
> newer. If your project must still run on JDK 17 to 24, use ClassGraph 5 until
> it can move to JDK 25. ClassGraph 5 has the same API and behavior as
> ClassGraph 6, and will be kept in sync with it for the near future. Both have
> a new API: the porting guide walks through the port from 4.x step by step,
> and a coding agent can follow it for you.
> {quote}
> *Related links:*
> * [https://github.com/classgraph/classgraph/releases/tag/classgraph-5.0.0]
> *
> [https://github.com/classgraph/classgraph/wiki/Porting-ClassGraph-4.x-code-to-ClassGraph-6.x]
> {quote}*_Use ClassGraph 6.x wherever you can, i.e. on JDK 25 or newer._* All
> legacy code has been removed from 6.x, including the workarounds for older
> JDKs and the reflection-based workarounds, so it is the most future-proof
> version. ClassGraph 4.x and 5.x are stop-gaps for projects that cannot yet
> run on a recent JDK.
> *ClassGraph 5.x.* This page describes ClassGraph 6.x, which requires JDK 25
> or newer. {color:#de350b}_ClassGraph 5.x has the same API and the same
> behavior, runs on JDK 17 or newer, and is kept in sync with 6.x for critical
> bug-fix releases._{color} To port to 5.x, follow this page and read "6.x" as
> "5.x" throughout. On JDK 17 to 24, two things behave differently, because the
> JDK does: below JDK 22, reading a memory-mapped ByteBuffer after the
> ScanResult or Vfs that owns it has been closed takes a SIGSEGV that kills the
> JVM, rather than throwing IllegalStateException (files are memory-mapped only
> on Windows, so this can only happen there); and on JDK 17 to 23, if you
> enable the Security Manager with -Djava.security.manager=allow, ClassGraph
> does not run its reflective calls inside AccessController#doPrivileged, so
> grant the calling code the permissions ClassGraph needs.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
