Hi
To bring some more insights into this thread, here the whole story of the JCAE and CA library:
Long time ago (I guess we first presented this on the Aix-en-Provence Epics Meeting) we at PSI wrote the JCAE library (which stands for JCA Extensions or something like this) to have a more Java like interface to the JCA channel access library (no need of dealing with DBR types, utility functions, etc.). JCAE is nothing than a wrapper and works starting from Java 1.4/1.6 .
Then a few years ago we contracted Matej to do a complete reimplementation of the Java Channel Access library. This reimplementation is stripping out all the (unnecessary) abstractions, is based on the ideas/insights we got from JCAE and is leveraging Java 8 functionality like Streams to make things even more simpler.
Right now we use both libraries in production. We use JCAE for old projects that started with this library, and CA for all new projects and whenever we do a bigger refactoring of existing applications.
My recommendation would also be like Matej’s
For client applications use the ca client library and if you need server functionality CAJ server.
So far there are no plans right now to also have the server functionality implemented in ca but everybody is invited to contribute this!
In general whenever you think things need to be added, changed or removed from the CA library please file issues, pull-requests, … on https://github.com/channelaccess/ca. Your contributions are more than welcome!
Best
Simon
Side note:
You might also have realised that there is a ca_matlab repository https://github.com/channelaccess/ca_matlab . This is the channel access library we use for Matlab. Right now its based on JCAE because the recent Matlab versions did not ship with a Java 8 runtime by default. As soon Matlab ships with Java 8 by default we switch to CA. The interface will stay unchanged, only a different import statement will be/is required (we already have Matlab apps running with CA and pointing to an external Java therefore we know).
> On 31 Jan 2018, at 09:08, [email protected] wrote:
>
> Hi,
>> Is ca the successor to JCAE:
>>
>>
>> https://github.com/paulscherrerinstitute/jcae
>>
>>
>> Both are developed at PSI, no?
>>
>> Are both used in production? Are both supported? What does the future
>> of JCAE look like?
>>
>
> I do not know JCAE. Quickly looking at the code it is a wrapper around JCA.
>
> I was funded by PSI to write “ca”. I reused stable CAJ core but ditched old JCA interfaces
> and replaced them with modern Java 8 interfaces. Afterwards PSI took over and added more
> features.
>
>> One thing I note is that it appears that JCAE has a client *and* a
>> server implementation, while ca has just a client. Is that right?
>>
>
> Right.
>> Are there plans to add a server implementation to ca?
>>
> I do not know.
> However, CAJ server side interfaces are more modern than JCA
> (but CAJS still use JCA DBR classes instead of generics).
>
>> Would JCAE still be a sound choice for a new project that needed a
>> client *and* a server implementation, or even a sound choice for a
>> project that needed just a server implementation? Or would it be better
>> to avoid it because it's being phased out, instead going with ca for the
>> client and CAJ (even though dated) for the server?
>>
> I would go with ca client + CAJ server.
>
> Cheers,
> Matej
- References:
- Re: Java API JCA / CAJ DBR_LONG matej . sekoranja
- Navigate by Date:
- Prev:
EPICS database macro warning Amien Crombie
- Next:
Phytron Phymotion reset on IOC boot Nilson Pereira
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Java API JCA / CAJ DBR_LONG matej . sekoranja
- Next:
Re: Java API JCA / CAJ DBR_LONG Ryan Slominski
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024
|