Re: EPICS 7 PVA for Java

["Williams Jr., Ernest L. via Core-talk" <core-talk@aps.anl.gov>]

Sent from my iPhone

On Jun 13, 2019, at 5:46 AM, Kasemir, Kay <kasemirk@ornl.gov> wrote:

Hi:

> By the way, are the following modules still relevant for EPICS 7 Java?

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

Kay, thanks for this.

I have not been following the developments in java until now.

Your email gives me some background and context.

I will work with Greg and the SLAC team on how we proceed with our middleware services for EPICS 

Cheers

Ernest