Mostly for historical reasons, the TurboVNC Viewer uses Java as a GUI toolkit. In the early 2010s, the Java TurboVNC Viewer received a great deal of funding from companies that were interested in deploying it as a web applet or a Java Web Start app. Thus, the Java TurboVNC Viewer evolved to the point at which it encompassed all of the critical features and performance of the native TurboVNC Viewer code bases, and it made sense to phase out the native code bases in favor of the Java TurboVNC Viewer with a built-in JRE. Since applets and Java Web Start are not supported anymore [^1], there is no technical reason why the TurboVNC Viewer couldn't be refactored as a native application. However, it would take a lot of labor. In addition to porting the TurboVNC Viewer base classes to C++ (or possibly reusing the TigerVNC Viewer base classes) and rewriting the GUI code, it would be necessary to refactor the TurboVNC Viewer’s built-in SSH client so that it uses libssh rather than a heavily modified version of JSch. I would probably want to use GTK as the GUI toolkit, due to its ubiquity and relatively small footprint, even though its API leaves much to be desired.
The current TurboVNC Viewer is deployed as a standalone application with a built-in JRE, as opposed to requiring a separate JRE, and it uses JNI for performance-critical subroutines (such as JPEG decompression) and O/S-specific workarounds for Java issues or limitations. Thus, refactoring it as a native application wouldn't really improve performance or usability. It would mainly improve maintainability, as well as facilitate supporting Wayland clients. (Java/Wayland is very much a work in progress, whereas popular C and C++ GUI toolkits have solid Wayland support these days.)
[^1]: Technically, JWS is still supported via IcedTea-Web by Adoptium and Azul. However, this requires installing and managing an IcedTea-Web application on all clients, which is of debatable usefulness relative to installing and managing a TurboVNC Viewer application on all clients.
Mostly for historical reasons, the TurboVNC Viewer uses Java as a GUI toolkit. In the early 2010s, the Java TurboVNC Viewer received a great deal of funding from companies that were interested in deploying it as a web applet or a Java Web Start app. Thus, the Java TurboVNC Viewer evolved to the point at which it encompassed all of the critical features and performance of the native TurboVNC Viewer code bases, and it made sense to phase out the native code bases in favor of the Java TurboVNC Viewer with a built-in JRE. Since applets and Java Web Start are not supported anymore [^1], there is no technical reason why the TurboVNC Viewer couldn't be refactored as a native application. However, it would take a lot of labor. In addition to porting the TurboVNC Viewer base classes to C++ (or possibly reusing the TigerVNC Viewer base classes) and rewriting the GUI code, it would be necessary to refactor the TurboVNC Viewer’s built-in SSH client so that it uses libssh rather than a heavily modified version of JSch. I would probably want to use GTK as the GUI toolkit, due to its ubiquity and relatively small footprint, even though its API leaves much to be desired.
The current TurboVNC Viewer is deployed as a standalone application with a built-in JRE, as opposed to requiring a separate JRE, and it uses JNI for performance-critical subroutines (such as JPEG decompression) and O/S-specific workarounds for Java issues or limitations. Thus, refactoring it as a native application wouldn't really improve performance or usability. It would mainly improve maintainability, as well as facilitate supporting Wayland clients. (Java/Wayland is very much a work in progress, whereas popular C and C++ GUI toolkits have solid Wayland support these days.)
[^1]: Technically, JWS is still supported via IcedTea-Web by Adoptium and Azul. However, this requires installing and managing an IcedTea-Web application on all clients, which is of debatable usefulness relative to installing and managing a TurboVNC Viewer application on all clients.