> (1) pvaClientJava
> (2) pvDatabaseJava
Not sure what type of answer you expect. A relevance rating from 0 to 50?
Java as in Oracle or the OpenJDK community probably couldn't care less about those two packages.
And how do you define EPICS 7? I would mostly look at the people who work on it.
If you like to use pvaClientJava and/or pvDatabaseJava, by all means use it and take on its maintenance.
At this time, we have pvData[Java,CPP], pvAccess[Java,CPP], pvDatabase[Java,CPP].
Michael Davidsaver is currently a key developer on the CPP side.
When implementing QSRV and the gateway, I think he decided that pvDatabaseCPP isn't adding value.
I've implemented PV support for CS-Studio (Eclipse-based and now Phoebus), but that's a client, so not using pvDatabaseJava.
I know several people who looked at the current XXX[Java,CPP] code and found that it's overly complicated because it's trying to be the same for the two languages, i.e. not taking advantage of each language, in fact quite the
opposite.
For the CS-Studio/Phoebus development, I'm looking into a new Java PVAccess client & server development that focuses on the needs of CS-Studio/Phoebus
and takes full advantage of Java. For example, using
Future<Data> read()
instead of a 'GetRequestor'. It's in the early stages, a first update could be expected at the BNL EPICS meeting.
If that works out, my relevance rating for pvaClientJava and pvDatabaseJava in their current form would be very low.
-Kay