As you know, modularity was recently deferred from SE 8 (and
transitively from EE 8), but since there will now be a longer delay
before core modularity can be leveraged, a few people were wondering if
the spec could provide some specific solutions to some of the more
dominant problems that developers are facing now. The most common one
that modularity would have solved is the "conflicting library problem".
This is when there exists a version of a library that is bundled with
the application but conflicts with a different version of the library
used by the server and that is exposed on the server classpath.
One way to solve this would be to provide a way for an application to
indicate that a bundled library is to be placed on the classpath
*logically ahead* of all server libraries. Most app servers offer some
proprietary solution to this problem, but there is currently no portable
way of doing it. If folks are agreeable then we would like to
standardize a solution in EE 7. We would first like to get your input as
to whether it is worth doing this, though.
In conjunction with the above question there is an additional question
relating to the limitation that we would need to impose in this initial
solution. Given that a) the majority of problem occurrences are due to
3rd party libraries being exposed by the server, and b) overriding a
Java EE API library is going to introduce a larger problem space than
what we would likely be able to solve in the time remaining in Java EE,
do you think it is worth providing a soution in EE 7 if that solution
was limited to 3rd party libraries and did not include support for
overriding Java EE APIs? Or, would you prefer to leave it until the next
release and include support for both, or even wait until EE 9 when
modularity will allow a more encompassing solution?
If enough people would like to solve the limited scope probem in EE 7
then we will follow up with a proposal and some additional questions.