我尝试在桌面Java应用程序中使用OpenCV Transparent API UMat类进行硬件加速，但是找不到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，而在下面没有看到 UMat 实现OpenCV Java Docs。
那么，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带来了面向管道/图形的范例。