> (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