On 11/18/11 12:36 AM, Tommaso Teofili wrote:
Sounds good, just I wonder how that could be managed in our build system,
but that's not the point.
More generally I was proposing Java 6 because interesting projects like
Hadoop, Hama and others that could be used for enhancing scalability use
that.
For Hadoop in particular it's a pity that huge systems like Watson have
this kind of integration UIMA+Hadoop and we can't offer it as open source
(I know there is something like that in the Behemoth project).
You maybe need to be more specific about which part exactly should be
Java 6 instead of Java 5.
For the addons packages it makes sense to allow Java 6 because there
we want to integrate things which depend on Java 6.
For the core framework I don't see what the advantage is to switch to
Java 6.
Because you can run it on Java 6, e.g. inside a Map Reduce job. That
already works.
In my production system UIMA runs also on Java 6 and we never had any
issues.
More generally it seems to me Java 6 would allow future enhancements
easier, if we have Java 5 too then it'd be hard to maintain something which
works on one version and something else that works on the other one.
Which enhancements do you think of? Are there any features in Java 6 you
would
like to use?
If you create a new user project which depends on Java 6 you can just
use UIMA
as it is, no need to worry about the Java version.
I can probably get back to this one when I have something more pragmatic
(code) which can support my proposal.
The next Java version which will have new interesting features might be
Java 8 with the
new module system. Maybe that is something we should base a UIMA 3.0
which could
contain also bigger changes.
Jörn
