Joerg Heinicke skrev:
On 10.08.2006 11:41, Daniel Fagerstrom wrote:
As Java 5 was released almost 2 years ago, I propose making it the
minimum requirement for trunk and all artifacts released from there.
-0, because this means eliminating cocoon 2.2 on "older" application
servers eg weblogic 8.1.
IIUC weblogic 8.1 uses servlet 2.3 so I guess you need to veto the
use of servlet 2.4 to make this a valid point.
Don't know about Weblogic (it was not my argument),
Joerg, vetoing a proposal is a serious issue as your single vote blocks
everyone else vote. That means that all argument for the veto must be
scrutinized so that we as a community can find a consensus based on facts.
And as your veto is based on among other things servlet container
compatibility we need to know if there are containers that we find it
important to support for 2.2 that doesn't work with Java 5.
but servlet spec does not matter that deeply IMO. I voted +1 on
servlet 2.4 mostly because of the request listeners. As long as the
2.4 features are kept out of core (which of them can surface
coincidentally?) we still can claim 2.3 compatibility and provide 2.4
features like request listeners as optional features. The same way
Spring is handling the request/session scoped beans by providing a
listener [1] (see Javadoc) and a filter [2].
The servlet API has always been a central part of Cocoon and with 2.2 it
becomes even more important as it is used instead of the Processor
interface. To follow what you say above means in practice that core
parts of Cocoon must not use 2.4 and that 2.4 can only be used in
optional blocks that no important functionality should depend on. The
vote about Servlet 2.4 was about using Servlet 2.4 in trunk. If you want
to achieve what you describe above you must veto that proposal and make
an alternative proposal.
If there are other use cases that require Java 1.4 you should
seriously consider if Simones proposal of using the Retroweaver would
be enough.
This works only as long as you don't use extensions made to the JDK
classes. Different JDK versions are not just about language features
but also about APIs. So this is no replacement IMO.
OK. So that bring us back to the key question: what specific problem
would we get by using Java 5?
Frankly, I don't see the point in upgrading unless there's a killer
feature in 1.5 that
1) we are likely to use and implement in the near future (2006) and,
2) will improve cocoon by a significant margin.
We never require something like that when we update the version on
libraries we depend on. For libraries we depend on the latest stable
version as long as it doesn't create any problems, we never require
that anybody is going to use the latest features.
Don't understand that point.
Our policy is to always use the latest stable version of all libraries
that we depend on. There are many good reasons for that: we get
presumably less buggy and better versions of the libraries, our adaption
becomes to newer versions becomes gradual instead of abrupt as we update
often and we help both the communities we depend on and ourselves by
testing early.
So our policy for updating libraries is far for what you require for
updating JDK. Also, not updating JDK will give us increasing problems in
using the latest stable version of used libraries as they are starting
to require Java 5.
For the "killer features", lots of people have said that they are
interested in using various features in Java 5, do you find your lack of
interest in these features a strong enough reason to prevent others from
using them?
I second this, but vote even -1. I wonder why a framework should set
such high requirements. Have a look on spring. They have a Java 1.3
as minimum requirement and only need Java 5 for special features.
IMO we should do it in a similar manner and not set the general
requirement to Java 5.
Cocoon is both a framework and a set of applications. Compared to
Spring, Cocoon is less framework oriented.
Understand what you want to claim, but can't follow. Why do you think so?
The core offering from the Spring framework is the bean factory, which
is a low level framework that is used in numerous other projects many of
which are used by still other projects in turn. Cocoon is a much higher
level framework, and is with a few exceptions used directly to build
applications with. This means that it is enough to ask our users what
they think, while Spring need to understand their users users. And
because of that need to be more conservative.
So, Cocoon and Spring are quite different kind of beasts, so we need to
understand why they support Java 1.3 to know if their reasons are
relevant for us.
If you want to follow the Spring policy I think you should formulate
an alternative proposal which describes when it is OK to use Java 5
and when it is not.
Isn't this quite easy? Always provide a Java 1.4 alternative and make
Java 5 features optional. See declarative transaction demarcation in
Spring. It's completely possible without Java 5. But you can use
annotations for it as well. And even those can be used with Java 1.4
and commons attributes IIRC.
Always providing a 1.4 alternative means a lot of extra, and fairly
boring, work. I think we better focus on one version.
I simply still can't see how Java 5 will help us significantly.
And if you keep your veto you will prevent all the rest of us who
believe that it would help us to explore if it will help us as well.
Look, there might be excellent reasons for not upgrading and if there
are it is better that we find them. And I agree with Jorg that if many
people who otherwise would use 2.2 don't because of Java 5, that would
be a good reason for waiting with upgrading to Java 5. But this far no
one have said that they would have any problems with it, neither at
cocoon-dev or cocoon-user.
/Daniel
