cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: [Vote] Java 5 as minimum JDK requirement
Date Tue, 15 Aug 2006 00:53:40 GMT
On 14.08.2006 22:19, Daniel Fagerstrom wrote:

> 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.

As I already said: servlet containers have not been my argument! I only 
added a comment to your first answer.

>> 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.

Of course.

> 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.

The above walk just talking in large. In the meantime I had a look into 
the 2.4 spec what actually changed since 2.3. And indeed besides minor 
refinements (IMO unimportant to Cocoon) it's only the request listener 
that's new. And even if Cocoon uses these features and does not provide 
alternatives I can live with it as it is only a small amount of code 
that would be needed to be implemented in case somebody needs really 
2.3. That's why I support the change to 2.4. The impact is very low. A 
bigger change in the API would probably have not gotten my approval as 
well ...

Besides this I don't really see how it is related to Java 5.

> OK. So that bring us back to the key question: what specific problem 
> would we get by using Java 5?

> 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.

I don't care that much about that point. There are not many libraries 
actually requiring Java 5. And besides that those might provide Java 1.4 
compatible releases as well.

> 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?

Missing interest is for sure not my reason to veto the change.

(This is getting me too personal here ... please don't imply such 
ignorance.)

> 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.

I absolutely can't agree. Both are just application frameworks - with 
Cocoon being more web-tied.

>> 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.

Might be. That was just my proposal instead of switching to Java 5.

>> 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.

No, no. Please stay serious. There are other playgrounds to explore Java 
5. It must not be Cocoon.

> But this far no one have said that they would have any problems with
> it, neither at cocoon-dev or cocoon-user.

This remains my main point though: losing some of our user base. You may 
never have been working for a bank, but there such changes in the 
requirements take years til they get applied. When we wrote an 
application based on Mozilla 1.0 the customer still used Netscape 4.0.x, 
not even the latest available version of Netscape at that time, which 
was 4.7.x IIRC. We fought for weeks until it was allowed to get Mozilla 
1.0 installed on their desktop computers. Andrew's mail from half an 
hour ago seems to affirm this.

Besides that such customers/users are often not active in the open 
source community. We all (at least visitors of Cocoon GT from 2 (?) 
years ago) know a famous example, where we could not even publish the 
name of a big company using Cocoon. Or the company I work for: We use 
many different open source libs. But I don't think there was much 
response to the community. And I still have to do bug fixes at home as I 
could not give back patches or code I did at work due to copyright 
reasons. You might just not have the majority of our user based involved 
here.

I still stand with my -1 vote. I don't want to be attacked personally 
for it. Sorry for it, but we don't agree here.

Regards,
Jörg

Mime
View raw message