Solo puedo decirles la opinión de mi organización sobre el asunto. Estamos en el proceso de cambiar a módulos, para cada proyecto en el que estamos trabajando. Lo que estamos construyendo es básicamente microservicios + algunas bibliotecas de clientes. Para los microservicios, la transición a los modules es de alguna manera una prioridad menor: el código allí ya está aislado de alguna manera en el contenedor de la ventana acoplable, por lo que "agregar" módulos allí no parece (para nosotros) muy importante. Este trabajo se está retomando lentamente, pero es de baja prioridad.

Por otro lado, las bibliotecas de clientes son una historia completamente diferente. No puedo decirte el lío que tenemos a veces. Voy a explicar un punto que odiaba antes de jigsaw . Expone una interfaz a los clientes, para que todos la usen. Automáticamente esa interface es public - expuesta al mundo. Por lo general, lo que hago es tener algunas clases package-private , que no están expuestas a los clientes, que usan esa interfaz. No quiero que los clientes usen eso, es interno. ¿Suena bien? Incorrecto.

El primer problema es que cuando esas clases package-private crecen y desea más clases, la única forma de mantener todo oculto es crear clases en el mismo paquete:

 package abc: -- /* non-public */ Usage.java -- /* non-public */ HelperUsage.java -- /* non-public */ FactoryUsage.java ....

Cuando crece (en nuestros casos lo hace), esos paquetes son demasiado grandes. ¿Pasar a un paquete separado dices? Claro, pero entonces HelperUsage y FactoryUsage serán public y tratamos de evitar eso desde el principio.

Problema número dos: cualquier usuario/llamador de nuestros clientes puede crear el mismo nombre de paquete y extender esas clases ocultas. Ya nos pasó un par de veces, momentos divertidos.

Los modules resuelven este problema de una manera hermosa: public ya no es realmente public ; Puedo tener acceso de friend a través exports to directiva. Esto hace que el ciclo de vida y la gestión de nuestro código sean mucho más fáciles. Y nos alejamos del infierno classpath. Por supuesto, maven/gradle maneja eso por nosotros, principalmente, pero cuando hay un problema, el dolor será muy real. Podría haber muchos otros ejemplos, también.

Dicho esto, la transición (todavía) no es fácil. En primer lugar, todos los miembros del equipo deben estar alineados; en segundo lugar hay obstáculos. Los dos más grandes que todavía veo son: ¿cómo se separa cada módulo, en función de qué, específicamente? Todavía no tengo una respuesta definitiva. El segundo es split-packages , oh, la hermosa "misma clase es exportada por diferentes módulos". Si esto sucede con sus bibliotecas, hay formas de mitigar; pero si se trata de bibliotecas externas... no es tan fácil.

Si depende de jarA y jarB (módulos separados), pero ambos exportan abc.def.Util , se llevará una sorpresa. Sin embargo, hay formas de resolver esto. Algo doloroso, pero solucionable.

En general, desde que migramos a módulos (y aún lo hacemos), nuestro código se ha vuelto mucho más limpio. Y si su empresa es una empresa "de código primero", esto es importante. Por otro lado, he estado involucrado en empresas en las que los arquitectos senior lo consideraban "demasiado caro", "sin beneficio real".

No.

No hay necesidad de cambiar a módulos.

Nunca ha habido necesidad de cambiar a módulos.

Java 9 y versiones posteriores admiten archivos JAR tradicionales en la ruta de clase tradicional, a través del concepto del módulo sin nombre, y probablemente lo harán hasta la muerte por calor del universo.

Ya sea que comience a usar módulos depende completamente de usted.

Si mantiene un gran proyecto heredado que no cambia mucho, probablemente no valga la pena el esfuerzo.

Si trabaja en un proyecto grande que se ha vuelto difícil de mantener a lo largo de los años, la claridad y la disciplina que brinda la modularización podrían ser beneficiosas, pero también podría ser mucho trabajo, así que piense detenidamente antes de comenzar.

Si está comenzando un nuevo proyecto, le recomiendo comenzar con módulos si puede. Muchas bibliotecas populares ya se han actualizado para convertirse en módulos , por lo que es muy probable que todas las dependencias que necesita ya estén disponibles en forma modular.

Si mantiene una biblioteca, le recomiendo encarecidamente que la actualice para que sea un módulo si aún no lo ha hecho y si todas las dependencias de su biblioteca se han convertido.

Todo esto no quiere decir que no encontrará algunos obstáculos al pasar de Java 8. Sin embargo, es probable que los que encuentre no tengan nada que ver con los módulos en sí . Los problemas de migración más comunes de los que hemos oído hablar desde que lanzamos Java 9 en 2017 tienen que ver con los cambios en la sintaxis de la cadena de versión y la eliminación o encapsulación de las API internas (p. ej ., sun.misc.Base64Decoder ) para las cuales Los reemplazos públicos y compatibles han estado disponibles durante años.