We shouldn’t be concerned about the support for writing plugins in Java and calling into C vs C++, since no one is doing it and I haven’t heard of anyone attempting it.
We should look at Luajit and V8 support for calling C++ APIs since that is the path we are on and going down. -Bryan > On May 17, 2019, at 10:04 AM, Walt Karas <wka...@verizonmedia.com.INVALID> > wrote: > > Is it somehow inherently more dangerous or disaster-prone than calling into > Lua code that calls back into the C TS API? > > On Fri, May 17, 2019 at 11:59 AM Jason Giedymin <jason.giedy...@gmail.com> > wrote: > >> Sounds like a disaster. >> >> -Jason >> >>> On May 17, 2019, at 12:51 PM, Bryan Call <bc...@apache.org> wrote: >>> >>> Having a plugin that would call into Java and then back into C sounds >> like a really bad idea. >>> >>> -Bryan >>> >>> >>>> On May 17, 2019, at 8:59 AM, Walt Karas <wka...@verizonmedia.com.INVALID> >> wrote: >>>> >>>> http://jonisalonen.com/2012/calling-c-from-java-is-easy/ >>>> >>>> I don't know if there is a way to call Java from C or C++, which you >> would >>>> also need to have a Java plugin. If no one is currently doing anything >>>> like this we probably shouldn't worry about it. >>>> >>>>> On Fri, May 17, 2019 at 10:54 AM Leif Hedstrom <zw...@apache.org> >> wrote: >>>>> >>>>> >>>>> >>>>>> On May 17, 2019, at 9:48 AM, Walt Karas <wka...@verizonmedia.com >> .INVALID> >>>>> wrote: >>>>>> >>>>>> But are there people who write plugins in other languages (like Java >> for >>>>>> example) that can call C functions, but not C++ functions? If so, >>>>> wouldn't >>>>>> this break their plugins? >>>>> >>>>> >>>>> Never heard of that. How would someone do that ? You can write Java >> such >>>>> that the C-callbacks / continuations from ATS somehow gets called into >> the >>>>> appropriate Java API? dlopen() would need to find all these entry >> points in >>>>> the .so. >>>>> >>>>> — leif >>>>> >>>>>> >>>>>>> On Fri, May 17, 2019 at 8:41 AM Leif Hedstrom <zw...@apache.org> >> wrote: >>>>>>> >>>>>>> If we change this, such that all plugins must be compiled with C++ >>>>>>> compilers, we have the liberty of using C++’ism in the public >>>>> interfaces, >>>>>>> such as ts/ts.h and ts/remap.h. This has benefits, such as being >> able to >>>>>>> expose internal APIs of ATS without going through complex glue >>>>> interfaces >>>>>>> and opaque pointers. >>>>>>> >>>>>>> The disadvantage is that keeping ABI compatibility is a fair amount >> more >>>>>>> tricky. However, I don’t feel this is a significant issue, as long >> as we >>>>>>> don’t break it within minor / patch releases. It does make things >>>>> trickier >>>>>>> here too though, so we have to be open to the possibility of >> accidental >>>>>>> breakage of ABI compatibility. >>>>>>> >>>>>>> I think the advantages outweighs the disadvantages. The tasks for >> this >>>>> is >>>>>>> tracked on >>>>>>> >>>>>>> https://github.com/apache/trafficserver/issues/5360 >>>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> — leif >>>>>>> >>>>>>> >>>>> >>>>> >>> >>