Le classi in una libreria JRE supportano letture osservabili e / o asincrone da assembly esterni / non JRE?

Come posso implementare la mia libreria multipiattaforma (ad esempio su JRE) per operare in modo thread-safe su riferimenti a oggetti, in modo che front-end nativi su altre piattaforme possano osservare l'oggetto e trarre vantaggio da schemi osservabili?

Un po 'di background: esiste un concetto di associazione dei dati utilizzato nella maggior parte dei framework front-end. In C # e Java questo è legato alla caratteristica Osservabile che dà a una classe la possibilità di lanciare eventi quando si verificano cambiamenti, a cui possono sottoscrivere più controlli o "osservatori". In questo modo gli osservatori non devono continuare a sondare / leggere la risorsa, confrontando per gli aggiornamenti.

Voglio lavorare su un motore di analisi che apporti modifiche agli elenchi di dati nel tempo. Sarebbe bello poter avere il front-end in grado di osservare questi elenchi mentre l'analisi è in esecuzione. Mi sembra che ciò richiederebbe al front-end di essere in grado di passare un oggetto al motore di analisi, scritto in una libreria che si spera sia multipiattaforma, e di poter eseguire letture thread-safe su quell'oggetto. Oppure, fai in modo che la biblioteca soddisfi i contratti di osservabilità.

Il modo in cui questo viene gestito nei vecchi motori CLI in stile Unix consiste nell'utilizzare stdin / stdout / stderr e fare in modo che il motore invii aggiornamenti a intervalli regolari. Ciò richiede un overhead standard e l'analisi del testo che preferirei evitare, se possibile.

Puoi creare un livello di integrazione sul modello della tua libreria usando (ad esempio) il framework di integrazione di apache camel. Il componente Netty probabilmente potrebbe soddisfare le tue esigenze. Con un modello osservabile, il livello di integrazione dovrebbe trasformare le modifiche ricevute del modello e notificarle agli abbonati front-end. Un altro modo simile per interpretare le tue esigenze è quello di pensare a un'architettura guidata dagli eventi in cui quando il tuo modello cambia, gli ascoltatori di osservatori nel tuo livello di integrazione pubblicano un messaggio in un argomento JMS in modo che gli abbonati collegati nei front-end li riceveranno.

Ho scritto una risposta completamente diversa, suggerendo che il tuo editore scrive gli aggiornamenti in una coda o in una pipe, ma poi rileggo la domanda.

Se ho capito bene la tua domanda generale è che vuoi scrivere una libreria da eseguire in JRE, in cui un front-end nativo può interrogare lo stato degli oggetti Java in maniera thread-safe.

Questo è incredibilmente ampio perché ci sono centinaia di modi in cui un front-end può interagire con il codice della libreria in esecuzione in un JRE: JNI, EJB RPC, interfacce HTTP in stile RPC, richiesta-risposta su code di messaggi, ecc.

Qualunque cosa tu scelga, tuttavia, a un certo punto della catena, dovrebbe esserci una chiamata al metodo Java, ed è qui che puoi prendere il controllo della sicurezza dei thread. Lì hai tutto l'arsenale di strumenti di sicurezza del filo a tua disposizione. Puoi sincronizzare, puoi restituire copie difensive, lavorare con i dati memorizzati nella cache, ecc.

Tuttavia, considera se questo è il modello che vuoi seguire. Potrebbe essere più pulito passare a un modello "non chiedermelo, ti dirò", in cui la tua libreria invia aggiornamenti al front-end contenente informazioni sufficienti che non è necessario interrogare gli oggetti.