As classes em uma biblioteca JRE suportam leituras observáveis ​​e / ou assíncronas de montagens externas / não JRE?

Como posso implementar minha biblioteca de plataforma cruzada (por exemplo, no JRE) para operar de maneira segura em threads em referências a objetos, para que front-ends nativos em outras plataformas possam observar o objeto e tirar proveito dos padrões Observáveis?

Um pouco de experiência - existe um conceito de ligação de dados usado na maioria das estruturas de front-end. Em C # e Java, isso está relacionado à característica Observable, que dá a uma classe a capacidade de acionar eventos quando ocorrem mudanças, nas quais vários controles ou "observadores" podem se inscrever. Dessa forma, os observadores não precisam continuar pesquisando / lendo o recurso, comparando para obter atualizações.

Quero trabalhar em um mecanismo de análise que faça alterações nas listas de dados ao longo do tempo. Seria bom que o front-end pudesse observar essas listas enquanto a análise está sendo executada. Parece-me que isso exigiria que o front-end pudesse passar um objeto para o mecanismo de análise, escrito em uma biblioteca que, esperançosamente, é multiplataforma e capaz de fazer leituras seguras de threads para esse objeto. Ou então, peça à biblioteca que cumpra contratos de observabilidade.

A maneira como isso é tratado nos mecanismos CLI mais antigos do estilo Unix é usar stdin / stdout / stderr, e fazer com que o mecanismo publique atualizações em intervalos regulares. Isso requer uma sobrecarga padrão e uma análise de texto que eu preferiria evitar, se possível.

Você pode criar uma camada de integração sobre o modelo da sua biblioteca usando (por exemplo) a estrutura de integração do apache camel. O componente Netty provavelmente pode atender às suas necessidades. Com um padrão observável, sua camada de integração deve transformar as alterações recebidas do modelo e notificá-las aos assinantes front-end. Outra maneira semelhante de interpretar seus requisitos é pensar em uma arquitetura orientada a eventos em que, quando seu modelo for alterado, os ouvintes observadores em sua camada de integração publiquem uma mensagem em um Tópico JMS para que os subscritores conectados nos front-ends os recebam.

Eu escrevi uma resposta completamente diferente, sugerindo que seu editor grave atualizações em uma fila ou um cachimbo - mas, então, reli a pergunta.

Se bem entendi, sua pergunta geral é que você deseja escrever uma biblioteca para executar no JRE, na qual um front-end nativo pode consultar o estado dos objetos Java de uma maneira segura para threads.

Isso é incrivelmente amplo, pois existem centenas de maneiras pelas quais um front-end pode interagir com o código da biblioteca em execução em interfaces JRE - JNI, EJB RPC, HTTP no estilo RPC, resposta de solicitação sobre filas de mensagens etc.

Qualquer que seja a sua escolha, em algum momento da cadeia, deve haver uma chamada de método Java, e é aí que você assume o controle da segurança de threads. Lá, você tem todo o arsenal de ferramentas de segurança de linha à sua disposição. Você pode sincronizar, pode devolver cópias defensivas, trabalhar com dados em cache, etc.

No entanto, considere se este é o modelo que você deseja seguir. Pode ser mais fácil mudar para um modelo "não me pergunte, eu vou lhe dizer", no qual sua biblioteca envia atualizações para o front-end contendo informações suficientes para que não seja necessário consultar os objetos.