Mensajes

Buen post, es bueno tomar este tipo de cosas muy encuentra. Una persona que viole este tipo de reglas fundamentales no lo considero un buen programador.

Hacia mucho que no se veía un tutorial de Java EE por estos lados. Y es el primero que veo en el foro, buen trabajo.

Saludos.

La forma mas fácil, rápida y simple es verificar si el tamaño del Set que haz creado es mayor a 1, si es mayor a 1 es porque contiene elementos con valores distintos. Los Set por naturaleza no contienen valores duplicados.



También puedes utilizar el nuevo feature para trabajar con colecciones en Java 8 (Stream).

Código (java) [Seleccionar] Expandir


    public static void main(String [] args) {
        Set<Double> numeros = new HashSet<Double>();
        numeros.add((double)222);
        numeros.add((double)223);
        numeros.add((double)224);
        numeros.add((double)222);
        numeros.add((double)222);
        System.out.println("Distintos: "+(numeros.stream().distinct().count() != 1));
    }

Result:

Código [Seleccionar] Expandir

Distintos: true
Saludos.

[8 General Programming . . . . . . . . . . . . . . . . . . . . . . . . .209]

En java no existe un estándar para Indentación.

Lo mejor es utilizar estilo del código ya existente o quizás el mismo estilo pero con algunos cambios. Ya que siempre se suele trabajar en equipo, la idea es que todo el que lea tu código se sienta aunque sea un poco familiar. Cuando el proyecto empieza se suele seguir el estilo de la persona a la que se le considera con mas conocimiento. Pero sobre el estilo de indentación, lo importante es hacer el código lo mas legible posible. Yo prefiero ver un código de 7 lineas que exprese muy bien lo que hace en cada linea a un código de 25 linea que utilice la mejor indentación que se ha identificado.

Y evita ligar el estilo de la programación estructurada en la programación orientada a objetos.

Por mi parte yo suelo utilizar el estilo de Allman.

Any fool can write code that a computer can understand.
Good programmers write code that humans can understand.

PD: En los documentos de Oracle, se hace mas enfatice en exponer lo que se quiere explicar lo mas simple posible a utilizar buenas practicas. Por eso encontraras documentos con ejemplos de código sobre algún tópico que violan los principios de la programación orientada a objetos.



Un gran libro con muy buenas practicas y que me sorprendio es: Effective Java (2nd Edition).

Siempre le doy una revisada, la verdad es un buen libro para tenerlo de referencia.

Te dejo algunos de los tópicos:

8 General Programming . . . . . . . . . . . . . . . . . . . . . . . . .209
Item 45: Minimize the scope of local variables . . . . . . . . . . . . . . . 209
Item 46: Prefer for-each loops to traditional for loops . . . . . . . . . 212
Item 47: Know and use the libraries . . . . . . . . . . . . . . . . . . . . . . . 215
Item 48: Avoid float and double if exact answers
are required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Item 49: Prefer primitive types to boxed primitives . . . . . . . . . . . 221
Item 50: Avoid strings where other types are more appropriate . . 224
Item 51: Beware the performance of string concatenation . . . . . . 227
Item 52: Refer to objects by their interfaces . . . . . . . . . . . . . . . . . 228
Item 53: Prefer interfaces to reflection . . . . . . . . . . . . . . . . . . . . . 230
Item 54: Use native methods judiciously. . . . . . . . . . . . . . . . . . . . 233
Item 55: Optimize judiciously . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Item 56: Adhere to generally accepted naming conventions . . . . . 237

Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .241
Item 57: Use exceptions only for exceptional conditions . . . . . . . 241
Item 58: Use checked exceptions for recoverable conditions
and runtime exceptions for programming errors . . . . . . . 244
Item 59: Avoid unnecessary use of checked exceptions . . . . . . . . 246
Item 60: Favor the use of standard exceptions. . . . . . . . . . . . . . . . 248
Item 61: Throw exceptions appropriate to the abstraction. . . . . . . 250
Item 62: Document all exceptions thrown by each method. . . . . . 252
Item 63: Include failure-capture information in
detail messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Item 64: Strive for failure atomicity . . . . . . . . . . . . . . . . . . . . . . . 256
Item 65: Don't ignore exceptions . . . . . . . . . . . . . . . . . . . . . . . . . 258

Generics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109
Item 23: Don't use raw types in new code . . . . . . . . . . . . . . . . . . . 109
Item 24: Eliminate unchecked warnings. . . . . . . . . . . . . . . . . . . . . 116
Item 25: Prefer lists to arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Item 26: Favor generic types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Item 27: Favor generic methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Item 28: Use bounded wildcards to increase API flexibility . . . . . 134
Item 29: Consider typesafe heterogeneous containers . . . . . . . . . . 142

En ese caso puedes utilizar la especificación JAX-RS (para resful) y montarla sobre un servlet container embebido como Jetty para que te manejé la concurrencia.

También pudieras utilizar JAX-RS sin ningún servlet container pero solo te daría atendería una petición a la vez a menos que manejes tu mismo la concurrencia pero esto te agregaría una complejidad innecesaria.

Otra opción también sería utilizar Netty.

Lo que pasa es que a la hora de generar el war con maven no te lo genera con la dependencia de B y ningún otra dependencia a menos que se lo especifiques.

Puedes este plugin de maven: maven-assembly-plugin. Tambien en la web puedes encontrar muchos ejemplos utilizando este plugin.

Otra cosa, ten en cuenta que el proyecto B debe ser un JAR, porque no puedes poner dentro de un WAR otro WAR.

Saludos.

RabbitMQ no es una librería, es un Message Broker. Cuando vi el mensaje que decía JSON y librería, pensé que necesitabas una librería para serializar de Java/Scala a JSON y deserializar de JSON a Java/Scala...

Cualquiera de los mas populares Message Broker te dará los resultados que necesitas porque todos se utilizan en sistema muy concurrentes y tienen grandes compañias detrás de ellos. Yo los únicos Message Broker que he manejado son los que vienen en los Application Server como Weblogic, Glasshfish, etc... Pero estos no te funcionaran directamente con otros lenguajes y estoy seguro que no es lo que quiere ni necesitaras.

Te puedo mencionar los siguientes Message Broker: ActiveMQ, zeromq, Apollo (basado en ActiveMQ's) y el mismo que habias mencionado (RabbitMQ).

Y si necesitas mas restricciones, mas exactitud a la hora de parsear los datos, ya que los datos que comunicas son muy complejos e incluso validar la estructura de los mensajes puedes reemplazar JSON por XML. Pero puede que te agregue complejidad al sistema y si no tienes todo el tiempo del mundo, te recomiendo que sigas con JSON ya que parece que tienes mas experiencia con el.

Saludos.

Siempre que trabajo con web services, antes de realizar un cliente para que consuma el web services, utilizo SoapUI para verificar que todo este correctamente y asi descarto que cualquier problema futuro pueda ser con el web services.

Yo obtuve la Oracle Certified Professional, Java SE 6 Programmer. La pase con un 93%, luego de casi dos meses de estudio (alrededor de 3h diarias). Mis compañeros de trabajo han tomado la Associate y la Professional de java SE 7.

Si te piensas certificar de la version 7, y quieres un buen plus para ingresar al mercado laborar, entonces toma 2 examenes. El primero es el Associate (1Z0-803, el mismo que menciona en el post) y luego el Professional (1Z0-804). La razón es porque el Associate no cubre topics que son muy importantes a la hora de desarrollar. La otra opción es tomar la versión 6 del examen, que es un solo y es la Professional.

Lo de si es verdadero útil, dependerá mucho del país donde vivas, pero de igual manera es un gran plus ya que los exámenes de Oracle "son los mas difíciles de la industria".

Te recomiendo a un 100% que estudies autodidacta-mente. Yo he tomado el examen de Java SE Programmer 6, y también he tomado e pasado el de Oracle Certified Expert, Java EE 6 Enterprise JavaBeans Developer. El próximo mes pienso tomar el de Oracle Certified Expert, Java EE 6 Web Services Developer y mis compañeros de trabajo siempre se están preparando para tomar exámenes de certificaciones. La forma mas rápida, segura y efectiva es estudiar uno mismo. Busca referencia de libros que las personas han estudiado para el examen de certificación (coderanch es una gran fuente de información). Otra parte muy importante son los mock-exams, te ayudaran bastante, ya que sabrás el nivel de preparación que tienes, y algunos te explican detalladamente porque fallaste cada pregunta.

Sobre los cursos, normalmente no profundizan mucho. Quizás un curso sea bueno para inicializarse en algo pero para certificarse no serán suficiente. Yo he tomado cursos en institutos de mi país, y curso directamente impartido por personal de Oracle contratado por la empresa donde trabajo, y se aprende mas estudiando de un libro... La ventaja de los cursos es que puedes preguntar cualquier cosa y obtendrás respuesta instantáneas, y puedes profundizar con el profesor sobre alguna duda.

Saludos.

PD: La segunda forma es mucho peor, porque cada vez que necesites consultar los datos tendrás que hacer un unmarshing, cargas algunos objetos con data redundante y no podrás utilizar JPA efectivamente ya que toda la data esta en una tabla. También te recomiendo guardar el XML que recibes en una tabla, por si en algún momento el unmarshing falla (ya sea porque la estructura de el XML u por otra cosa), tendras la data de todos modos y luego podrás examinarla e procesarla.