cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [Vote] Java 5 as minimum JDK requirement
Date Mon, 14 Aug 2006 20:19:28 GMT
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


Mime
View raw message