Toolkit 5 should benefit of JDK 1.5

[Jani Laakso]

Especially data containers (use generics) would benefit of this big time.

Please list the * facts * why we burden our product with JDK 1.4?

Note, we do not have to enhance everything from 1.4 => 1.6, lets start from most important places such as Toolkit data containers.

[Marc Englund]

Quick thoughts:

Customers might require 1.4 compatibility (old application servers or whatever). At some point, this will not be a problem anymore - environments requiring 1.4 will be scarce. Have we reached that point?

Personally, I don't know. Need to find out if there are platforms / application servers widely in use that are not compatible? IDEs? Other problems?

Is it possible to compile all required libs as 1.4 compatible and use those in any AS? Will these libs conflict with those provided by the AS?

IMO the main reason why we still have 1.4 support is because 1.5 is likely to cause problems on some platforms, and we have not had (do not have?) the time to find out what problems and how to fix / work around them.

[Joonas Lehtinen]

Dropping support for 1.4 is easy. Designing how to fully utilize 1.5 is a large task (I would not budget less than 150h for design and implementation).

[Jani Laakso]

There's no point to budget anything for this. Correct solution is to * allow JDK 1.5 * and tip our developers that now you actually can, if you want to, use JDK 1.5. I bet new server-side code would slowly start using JDK 1.5 tweaks, especially on Toolkit collection enhancements.

Every month we postpone this => new server-side code loses JDK 1.5 benefits which otherwise would be free.

Again, I am not looking for major overhaul, just implicit (=free) enhancements with slow progress..

[Joonas Lehtinen]

"Correct solution is to * allow JDK 1.5 * and tip our developers that now you actually can, if you want to, use JDK 1.5."

What this means? Everyone understands that you can use 1.5 (as well as 1.6) and Toolkit 5 together. What people would like to have is that Toolkit 5 API:s would be built on concept of generics and we would use annotations in a meaningful way. We are there already - nothing to do.

In order to do these - we should probably introduce new redesigned data layer that would be more intuitive and easy to use that the current one. Designing such thing in coherent way is not a couple-of-days task. Unfortunately. This is a major task. When the benefits exist, we have a reason to drop support for 1.4.

Not to be misunderstood. Propose that: 1) We try to find out list of servers that do not support 1.5 and decide when de drop 1.4 support. 2) Brainstorm and innovate what we could achieve with 1.5 3) Design and implement datalayer prototype built on concept of generics 4) List the benefits 5) Decide on how to deprecate the old data-layer

I also propose that this will not be done in 5.0. (Maybe 5.1)

[Marc Englund]

Replying to Joonas Lehtinen:

"Correct solution is to * allow JDK 1.5 * and tip our developers that now you actually can, if you want to, use JDK 1.5." What this means? Everyone understands that you can use 1.5 (as well as 1.6) and Toolkit 5 together.

An attempt to clear things up a little: I think you guys are talking about different things - everyone does indeed know you can use tk5 with 1.5, but I read "allow JDK 1.5" as allowing _our_ developers to use 1.5 _in_ tk5 (e.g "allowing tk5 team to use generics" vs. "implementing generics API").

However, since libraries can't be just a little incompatible, this is not a gradual process - when the first 1.4 incompatible API call is committed, tk5 is no longer 1.4 source-compatible.

We should avoiding 1.5 until we actually implement an API for making use of 1.5 features: yes, allowing 1.5 stuff would be convenient for _our_ developers, but since someone developing _with_ tk5 will not see these changes, we only remove one feature (1.4 compatibility) without adding anything.

[Matti Tahvonen]

Now possible since dropping java 1.4 support. see #1779

This is a meta ticket. Should be split to individual tasks.