Dá pra fazer em Java?

Sim.

Use uma linguagem de script integrada à sua aplicação, como esta aqui: http://groovy.codehaus.org

Não é tão fácil quanto você quer, mas você precisa procurar por “ORM” - “Object-Relational Mapping”, e provavelmente você vai ter de aprender o Hibernate ou o TopLink.

Você pode fazer isso com Listeners e objetos de eventos. Repare que o problema não é bem “como fazer em Java”, mas “como fazer”, de uma maneira geral.

Nunca fiz isto na prática pois sou novato no java. Mas pela teoria eu tentaria implementar isto com classes de interface. Não servem pra isto?
Veja este comentário publicado em um fórum de java:

ctdaa:

Nunca fiz isto na prática pois sou novato no java. Mas pela teoria eu tentaria implementar isto com classes de interface. Não servem pra isto?
Veja este comentário publicado em um fórum de java:

Outra questão interessantíssima em relação ao uso das interfaces é no design do sistema. Se você usá-las adequadamente, você elimina o acoplamento direto entre as classes, fazendo com que o seu código seja modificável e, consequentemente, garantindo escalabilidade para que o seu sistema cresça sem grandes crises

As interfaces fornecem um meio que permite que você lide com os objetos sabendo apenas a assinatura de seus métodos, ou seja, seus comportamentos, sem que você dependa da (ou precise saber sobre a) implementação de determinadas classes. Tipo uma caixa-preta: você sabe o que deve entrar e o que deve sair, mas não se importa de como esse processamento é realizado.

E você deve estar perguntando: mas qual a diferença entre depender de uma classe ‘normal’ e depender de uma interface?? Simples: Você pode substituir a criação dos objetos por objetos de outras classes que implemente as interfaces dependentes e, sem muito esforço, você é capaz de modificar o seu sistema da maneira que desejar!

Dê uma lida sobre Design Patterns e acredito que a utilidade das interfaces ficará evidente para você!

Abraços!

---

Daniel F. Martins
Website, Blog

“Classes de interface” não existem. O que existe são classes e interfaces, são dois conceitos diferentes em Orientação a Objetos. De qualquer maneira, interfaces são um recurso bem básico da linguagem, e usar interfaces por usar interfaces não resolve o problema. Eu citei listeners (um padrão de projeto) partindo do caso específico que o colega citou e é a maneira que fazemos aqui, e é assim porque temos um framework de persistência próprio. De qualquer maneira, é o tipo de coisa que fazemos em tempo de desenvolvimento, não em implantação.

Ainda acho que usar uma linguagem de script é, de longe, o caminho mais fácil para fazer o que ele quer.
Os tais programas seriam scripts, compilados em tempo de execução.

É claro que talvez ele precise de uma ou outra interface, que o script precisará implementar. De qualquer forma, vejo poucas chances de retirar o código hardcoded, caso não se use uma tecnologia assim.

O ibotirama, dono do tópico, pode explicar melhor o que ele quer fazer, me diga se estou errado, mas o que entendi é que ele quer ter um sistema aplicativo “empacotado”, o cliente adiquire o pacote e na implantação o instalador pode fazer pequenas adapatações escrevendo estas rotinas que serão acionadas em locais pré-determinados, os tais “pontos de entrada”. Este é um conceito antigo de programação e bastante usado.
Por isso não estou entendendo as sugestões de “linguagem script” ou ORM… o que tem haver com o caso?
Pensei na interface pois o sistema poderia ter as chamadas à estas classes nos pontos estratégicos, implementada com código “vazio”… aciona o método mas não faz nada… O instalador, havendo a necèssidade, pode “implementar” o código destes métodos resolvendo os problemas específicos do cliente.

Pequeno exemplo para ilustar a teoria:
Classe principal:

package patternsample;

import java.lang.reflect.Method;
/**
 *
 * @author ctdaa
 */
public class Main {
    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) {
        // dados exemplo:
        UserData myUserData=new UserData("jose", "rh", 2500.00);
        // nome da user exit que deve ser acionada
        // este nome pode vir de um arquivo de propriedades
        //String myUserExit="patternsample.UserExit1";
        String myUserExit="patternsample.MyUserExit1";
        try {
			Class c = Class.forName(myUserExit) ;
            Class parms[] = new Class[1];
            parms[0]=UserData.class;
            Method meth = c.getMethod("call", parms);
            meth.invoke(c, myUserData);
		} catch (Throwable excecao) {
			excecao.printStackTrace();
			System.exit(16);
		}
        // procedimento normal após user exit
        StoreManager.addUser(myUserData);
    }
}

UserExit1: modelo de implementação com código vazio

package patternsample;

abstract class UserExit1 {
    static public void call(UserData ud) {
        
    }
}

MyUserExit1: código implementado para adaptações no cliente:

package patternsample;

public class MyUserExit1 extends UserExit1 {
    static public void call(UserData ud){
        System.out.println("acionando myUserExit1");
        double newSalary=(ud.getSalary() * 1.2);
        ud.setSalary( newSalary ) ;
    }

}

PS: Entendi também a sugestão da linguagem de script… o cliente pode implementar os scripts que são executados nos pontos de entrada. Mas neste caso o cliente ou instalador deverá conhecer mais uma linguagem, e os erros de execução podem atrapalhar.

Exatamente ctdaa, isso mesmo, é isso aí, mas eu gostaria de saber se o cliente implementando o ClientExit1.java, funciona mesmo o software estando todo empacotando, ou seja ele não tem os outros arquivos java, apenas os jars da vida ?.

A solução do seu problema passa pelo que se chamam “pontos de extensão”. Esse nome não é apenas desse produto que vc conhece. É um nome geral. O problema é como definir esses pontos e como definir a extensão. O Eclipse utiliza a tecnologia do OSGI para conseguir isso. Veja que não basta apenas escrever um script, é necessário conhecer as suas dependencias. Se o script for autosuficiente - ou seja, não chama bibliotecas diferentes das bibliotecas da aplicação pai, então a solução de usar uma linguagem de script -como o Vini falou , é concerteza o mais simples.

Mas vc precisa definir os pontos onde os scripts poderão ser colocados e descrever o que eles podem fazer.
Para isso a forma mais simples é definir uma interface que tenha os métodos necessários. Ai vc cria uma implementação padrão para essa interface que fará o mecanismo padrão. Através da API de Scripting vc consegue carregar essa interface implementada em script (grrovy ou javascript ou qq outro que vc queira: javascript é interressante porque não requer mais bibliotecas que o jse normal).
O objeto carregado pelo script substituiria o outro.

Outra opção é definir aspetos. Isto é mais simples conceitualmente, mas difícil na prática. Vc teria objetos que executam métodos antes, depois, ou em vez dos métodos padrão. Então para um método “emitirNota” vc teria um aspecto em torno desse método que executa um método classe do aspecto antes de chamar o “emitirNota”, um método que é chamado depois ou um método que é chamado em vez, substituindo o método original (esta opção é poderosa mas perigosa, sugiro que utilize apenas métodos antes e depois)
O script pode ser utilizado para criar este tipo de objetos.

Utilizar o padrão Observer ( listeners) não funciona para este caso porque não estamos reagindo a um evento, estamos interceptando o evento e fazendo coisas a mais ou diferentes.

É justamente aí que pode entrar a linguagem de script. O script é um código que roda na VM Java, com uma sintaxe super simplificada, mas que também é compilado para um .class. A diferença, é que ele é compilado em tempo de execução. Assim, você embarca um compilador do groovy dentro da sua aplicação, que executará enquanto o programa estiver rodando.

Por ter uma sintaxe mais simples, é mais adequado também para usuários finais, ou programadores de campo, que não tem tanto domínio assim de uma linguagem pesada como o Java. No caso do Groovy, o script poderia até implementar a classe UserExit1.

Acredito que de para fazer o que vc quer em Java sim.

Eu desenvolvo em sistema Protheus utilizando a linguagem Advpl. Eu estou estudando um forma de fazer a mesma coisa que vc esta querendo em JAva. Uma das coisas que fiz foi armazenar as informações dos campos das minhas telas de cadastro na base de dados. Assim dessa forma eu posso definir quais campos estão visiveis na tela de cadastro, criar consultar customizadas, entre outros detalhes. Com os meus campos informados na base de dados eu consigo montar automaticamente minhas telas de cadastro, semelhante ao sistema Protheus da Microsiga, altero a ordem dos campos, coloco os campos outros guias, isso sem precisar recompilar o meu projeto ficando tudo configurado na base de dados.

Mas ainda estou tentando achar um melhor forma de criar esses pontos de entradas na aplicação

Isso mesmo Paulo :lol: , Mas tenho outra questão, nos pontos de entrada muitas vezes os dados ainda não foram mandados para o topconnect ou para o banco de dados relacional, ou seja provavelmente estão na memória, como fazer com que os dados da memória sejam visíveis dentro do script do ponto de extensão, ou seja como fazer com que os dados da Nota Fiscal, fiquem visíveis no ponto de extensão NF001 ?

Grato.

Uma idéia que talves de certo e você usar interfaces java. Por exemplo:
Você tem um ponto de entrada chamado NF001 sua interface poderia ser

Essa interface poderia ser um ponto de entrada para validar as notas fiscais antes de salvar

public interface NF001{
    
    // Nos parâmetros do método espera o objeto mais poderia ser um array
    public boolean ValidaNota(NotaFiscal nfiscal, List<ItensNota> itensNota);  
 
}

Ai você criaria uma classe que implemente essa interface

public class NF001 implements NF001{

    public boolean ValidaNota(NotaFiscal nfiscal, List<ItensNota> itensNota){
           ////Faz alguma coisa   
    }

}

Ai teria que ver a melhor forma de carregar essa classe, Talves via ClassLoader, e registrar ela no sistema