我试图在桌面Java应用程序中使用OpenCVTransparent APIUMat类进行硬件加速，但是我找不到UMat类实现。我正在使用OpenCV version 4.1，其中说T-API的Java绑定可以从version 3.0开始使用，例如here：
T-API（透明API）已被引入，这是透明的GPU加速层使用OpenCL。它不增加任何编译时间或OpenCL的运行时依赖项。当OpenCL可用时，将检测到和使用，但可以在编译时或运行时禁用它。它涵盖约100个OpenCV函数。这项工作已按合同完成，在AMD和Intel公司的大力支持下。
T-API是否已弃用？如果是，则用什么代替？OpenCV Graph API G-API是什么？它是T-API的替代品吗？让我们分解这个问题。
T-API是否已弃用？如果是，用什么代替？
不，T-API尚未有效弃用。您可以看到here，T-API在OpenCV 4.1.2版本标记下仍然有效。 您的主要问题是T-API没有实际的Java包装器，因为我们可以看到at this answer，而在OpenCV Java Docs下看不到UMat实现。
还有，什么是OpenCV Graph API G-API？它是T-API的替代品吗？
再次，看着the docs，我们读：
OpenCV 3.0引入了透明API（或T-API），该API允许将OpenCV函数调用透明地卸载到OpenCL设备，并使用cv :: UMat保存主机/设备数据传输，这是向前迈出的一大步。但是，T-API是动态API –用户代码仍然不受限制，并且OpenCL内核以任意顺序排队，从而消除了进一步的管道级优化潜力。 G-API将隐式图形模型引入了OpenCV 4.0。图形模型捕获管道中的所有操作及其数据依赖性，因此为G-API框架提供了额外的信息来进行管道级优化。
据记载，G-API似乎不是“替代品”，而是OpenCV硬件加速计划的改进和改进。 G-API不仅对未组织的内核进行了一些优化的操作，还为新版本的OpenCV带来了面向管道/图形的范例。