Apache Directory Project - Shall we go JDK 1.5 in 1.1 branch

Author

Shall we go JDK 1.5 in 1.1 branch

Alex Karasulu

2006-03-07, 2:45 am

SUN just retired JDK 1.4. Shall we go 1.5 in the 1.1 branch? 1.0 can
be for jdk 1.4 use.

Alex

peter royal

2006-03-07, 2:45 am

Norbet Reilly

2006-03-07, 2:45 am

Not that it neccessarily concerns you guys, but the biggest problem we
have re JDK version upgrades is IBM's websphere appserver which always
seems to lag far behind due to having its own IBM-authored JVM.

Our customers aren't keen to upgrade until websphere has, which ties our ha=
nds.

I gather that pretty much all new work will be going into AD 1.1 after
a month or so, correct?

Alex Karasulu

2006-03-07, 2:45 am

Norbet Reilly wrote:
> Not that it neccessarily concerns you guys, but the biggest problem we
> have re JDK version upgrades is IBM's websphere appserver which always
> seems to lag far behind due to having its own IBM-authored JVM.
>
> Our customers aren't keen to upgrade until websphere has, which ties our hands.
>
> I gather that pretty much all new work will be going into AD 1.1 after
> a month or so, correct?
>
I think so norbet. All new features will go into 1.1. 1.0 is a feature
frozen branch where we only fix bugs as they are reported.

Alex

Norbet Reilly

2006-03-07, 2:45 am

As I suspected ... but ouch ;-)

Can I ask where you heard about JDK1.4 being dropped? The Sun J2SE
download area doesn't include it anymore, but I get the feeling that
is just as a bug as J2EE 1.2 is still downloadable and not
end-of-lifed yet...

Alex Karasulu

2006-03-07, 2:45 am

Norbet Reilly wrote:
> As I suspected ... but ouch ;-)
>
> Can I ask where you heard about JDK1.4 being dropped? The Sun J2SE
> download area doesn't include it anymore, but I get the feeling that
> is just as a bug as J2EE 1.2 is still downloadable and not
> end-of-lifed yet...
>
This is exactly what I noticed. Sun seems to be kicking us to move from
1.4 this way.

Alex

Trustin Lee

2006-03-07, 2:45 am

On 3/7/06, Alex Karasulu <aok123-Bdlq13kUjeyLZ21kGMrzwg@public.gmane.org> wrote:
>
> SUN just retired JDK 1.4. Shall we go 1.5 in the 1.1 branch? 1.0 can
> be for jdk 1.4 use.

Another big +1 here.

Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6

Emmanuel Lecharny

2006-03-07, 2:45 am

Norbet Reilly a écrit :

>Not that it neccessarily concerns you guys, but the biggest problem we
>have re JDK version upgrades is IBM's websphere appserver which always
>seems to lag far behind due to having its own IBM-authored JVM.
>
>Our customers aren't keen to upgrade until websphere has, which ties our hands.
>
>I gather that pretty much all new work will be going into AD 1.1 after
>a month or so, correct?
>
>
>
Hi Norbert,

your concern is right, as far as IBM consider that WebSphere 5.x is
still a live product. By the end of this year, WebSphere 5.x will be
dead and all IBM users will be ask to switch to WebSphere 6.x, if they
want to be supported.

I know that customer with working applications may perfectly continue to
run them on non maintained versions of WS, but we still have a 1.0
version which will be perfect for that. btw, WebSphere 4.0 is using a
1.3 version JDK, and we still have people around the world using WS4
(trust me : I'm a living witness

So having a 1.0/jdk 1.4 version and a 1.1/jdk5 version just seems
reasonnable to me.

I'm just thinking about Geronimo which needs a 1.4 JDK compatible source
base. What should we do? Do we have to "inject" all the new features we
will pour into 1.1 back to 1.0 ? That's the good question in my mind. I
don't know if we should tighten ADS developper (I'm thinking of Mina)
into a JDK version that does not fit their needs, and I don't know if we
should do it the Tomcat way (having a 5.0/JDK1.4 and a 5.5/JDK5
versions), which will generate more work for all of us.

Further more, the longer we will wait for this move, the more we will be
stuck with the user base on old JVM...

I'll vote +1, strongly.

Ersin Er

2006-03-07, 2:45 am

Alex Karasulu wrote:
> SUN just retired JDK 1.4. Shall we go 1.5 in the 1.1 branch? 1.0 can
> be for jdk 1.4 use.
>
> Alex
Although 1.5 will make life really easier we should think about it
carefully. 1.1 will probably be released in 4-5 months and so in this
case we assume that the users will adopt 1.5 by this mid-summer. (Will
they be ready?) It will make things easier for developers but the more
important is users. But I still favor 1.5 from a technical point of view.

--
Ersin

Norbet Reilly

2006-03-07, 2:45 am

Thanks for the update on IBM's plans.

Are you certain that WAS 6 is delivered with JDK1.5, that wasn't my
expectation and a quick google showed up some people using WAS 6 and
JDK1.4. Looking at
http://www-306.ibm.com/software/web...v/was/features/ it
seems it supports J2EE 1.4 (which Sun says needs JDK 1.5) but only JDK
1.4, so presumably they're using some additional back-ported JDK1.5
libraries but only the JDK1.4 JVM.

Anyway, I know websphere support isn't most probably a pivotal issue
for the AD development community, but I just trying to point out that
mandating JDK1.5 at this point may cut you off from some otherwise
keen customers - like me ;-)

Simon.Temple-bNHniqfy2KDk7dXyY5I9mNBPR1lH4CV8@

2006-03-07, 7:45 am

I'd rather you stick with JDK 1.4.

IMHO:

DS is, for many, a brand new technology and to rush to a new JDK so soon I
feel would be a mistake.

Early adopters of your technology are only just starting to get to grips
with it. Ensuring DS JDK stability in the current and next release will
ensure its adoption... even on old IBM JVM's ;-)

SimonT

07 March 2006 03:06
To: dev-aYN4UCa7k1r1N9kud6OZbmD2FQJk+8+b@public.gmane.org
cc:
From: Alex Karasulu <aok123-Bdlq13kUjeyLZ21kGMrzwg@public.gmane.org>
Subject: Shall we go JDK 1.5 in 1.1 branch

SUN just retired JDK 1.4. Shall we go 1.5 in the 1.1 branch? 1.0 can
be for jdk 1.4 use.

Alex

daune.jf-/BlEExAzoZbjMQX/wY3yqAC/G2K4zDHf@publ

2006-03-07, 7:45 am

We personally have been using Java 1.5 for more than one year.

But it is true that other users will probably stick to pre-1.5 for some time.

Maybe http://retroweaver.sourceforge.net could be the key to satisfy everyone.

Cheers,

J-F

Trustin Lee

2006-03-07, 7:45 am

On 3/7/06, daune.jf-/BlEExAzoZbjMQX/wY3yqAC/G2K4zDHf@public.gmane.org <daune.jf-/BlEExAzoZbjMQX/wY3yqAC/G2K4zDHf@public.gmane.org> wrote:
>
> Maybe http://retroweaver.sourceforge.net could be the key to satisfy
> everyone.

+1

Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6

Noel J. Bergman

2006-03-07, 5:45 pm

If ApacheDS requires JDK 1.5, you will entirely limit the market able to
embed the server. Many will not require JDK 1.5 for quite some time.

--- Moel

Noel J. Bergman

2006-03-07, 5:45 pm

> Are you certain that WAS 6 is delivered with JDK1.5

WAS 6 ships with JDK 1.4, and always uses its own, provided, Java
environment.

In the rush to adopt the latest JDK, keep in mind that you will be
abandoning the bulk of deployments, potentially for years to come. We only
just dropped JDK 1.3 in JAMES.

Other than cleaner support for SSL in MINA, what are the primary benefits to
ApacheDS for dropping JDK 1.4 support?

JDK 1.4.2 was most recently updated a couple of weeks ago, and has not
moved: http://java.sun.com/j2se/1.4.2/index.jsp.

--- Noel

Alex Karasulu

2006-03-07, 5:45 pm

Norbet Reilly wrote:
> Thanks for the update on IBM's plans.
>
> Are you certain that WAS 6 is delivered with JDK1.5, that wasn't my
> expectation and a quick google showed up some people using WAS 6 and
> JDK1.4. Looking at
> http://www-306.ibm.com/software/web...v/was/features/ it
> seems it supports J2EE 1.4 (which Sun says needs JDK 1.5) but only JDK
> 1.4, so presumably they're using some additional back-ported JDK1.5
> libraries but only the JDK1.4 JVM.
>
> Anyway, I know websphere support isn't most probably a pivotal issue
> for the AD development community, but I just trying to point out that
> mandating JDK1.5 at this point may cut you off from some otherwise
> keen customers - like me ;-)
>
Well what about 1.0 is this not something that satisfies your needs?

Alex

Alex Karasulu

2006-03-07, 5:45 pm

Noel J. Bergman wrote:
>
> WAS 6 ships with JDK 1.4, and always uses its own, provided, Java
> environment.
>
> In the rush to adopt the latest JDK, keep in mind that you will be
> abandoning the bulk of deployments, potentially for years to come. We only
> just dropped JDK 1.3 in JAMES.
>
> Other than cleaner support for SSL in MINA, what are the primary benefits to
> ApacheDS for dropping JDK 1.4 support?
>
> JDK 1.4.2 was most recently updated a couple of weeks ago, and has not
> moved: http://java.sun.com/j2se/1.4.2/index.jsp.
>
Ok I see I had thought it had reached it's EOL already and SUN yanked it
to force users to "move on." This is a bit crazy to think I know but
the 1.4.2 version was gone from their site for almost 2 weeks. Anyhow
with this knowledge I don't know what to think.

All I know is this though. I will probably not veto any move to use
this retroweaver stuff but I'm a -0 on it. Something about it does not
sound right. I don't like the idea of bytecode massaging at all. Maybe
because it screws up my debugger making it freak out. Is this a valid
concern? Perhaps this is best on another thread.

Regarding this thread though, Noel you make good points as usual.
Perhaps the retroweaver approach can help but I have no knowledge of
what it can do. Does it works when we depend on 1.5 API's that are not
in the 1.4 JDK and "weave" to 1.4. Again I'm digressing to another thread.

Sounds like we need more consideration before jumping to 1.5 JDK.
However people are ignoring the fact that we have a living supported 1.0
branch in the works and it was started just a month ago. Why the big
reaction? If people need a directory to embed it can they not stick to
1.0. Do they need all the fancy features in 1.1?

Or shall we keep the new features and enhancements in 1.1 modest and
release a stable 1.2 before we make the JDK 1.5 leap? Where can we
moderate and compromise here?

Thanks to all for participating in this thread. It's a particular PITA
because we've had this one before. But please keep voicing your
opinions. This is the only way to make sure we take care of everyone's
needs to the best of our ability.

Alex

peter royal

2006-03-07, 5:45 pm

Trustin Lee

2006-03-07, 5:45 pm

On 3/7/06, Alex Karasulu <aok123-Bdlq13kUjeyLZ21kGMrzwg@public.gmane.org> wrote:
>
> All I know is this though. I will probably not veto any move to use
> this retroweaver stuff but I'm a -0 on it. Something about it does not
> sound right. I don't like the idea of bytecode massaging at all. Maybe
> because it screws up my debugger making it freak out. Is this a valid
> concern? Perhaps this is best on another thread.

Retro(weaver|translater) won't change much of the originally compiled
classes. It won't harm debuggability AFAIK though we need to test it. I
think we definitely have to test if it works fine with debugger and what it
cannot provide us.

The biggest problem will be checking runtime compatibility because these
translaters won't provide some classes or methods which exists only in Java
5 API. But I think this will be resolved by providing more unit tests,
which is our long term goal.

Sounds like we need more consideration before jumping to 1.5 JDK.
> However people are ignoring the fact that we have a living supported 1.0
> branch in the works and it was started just a month ago. Why the big
> reaction? If people need a directory to embed it can they not stick to
> 1.0. Do they need all the fancy features in 1.1?

Yes we need to experiment with these translators. MINA is relatively a
small project comparing to ApacheDS, so we could experiment with it.

As always, migration from one version of JDK to other version is both a
sensation and PITA. :D

So my idea is to experiment the translators so we can decide. The biggest
issues here are two:

* Is the translated class debuggable? (Perhaps yes)
* Does the translator warn if unsupported API is used? (Perhaps no, but
it's OK if we have enough unit tests.)

Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6

Enrique Rodriguez

2006-03-07, 5:45 pm

On Mar 7, 2006, at 9:05 AM, Noel J. Bergman wrote:
> Other than cleaner support for SSL in MINA, what are the primary
> benefits to
> ApacheDS for dropping JDK 1.4 support?

FYI, we discussed this on 22-SEP-2005. At that time I stated, and still
feel:

"I've been looking forward to this for a while now. 1.5 has been out
for over a year and given how much more time we need to complete the
roadmap, let alone any sort of enterprise adoption, it makes perfect
sense to take advantage of many of the features in 1.5. In addition to
SASL, we already require 1.5 for SSL in MINA and I, for one, would like
to use some of the new concurrent collections and crypto."

Util-concurrent and newer crypto can be covered by other means, but I
feel strongly about SASL. SASL is the predominate security mechanism
for authentication with LDAP in SSO (Kerberos) environments. All the
modern (Windows 2000/2003/XP) interactions with MS AD use SASL and it's
a key feature of OpenLDAP over ApacheDS at the moment.

Enrique

Alex Karasulu

2006-03-07, 5:45 pm

Trustin Lee wrote:
> So my idea is to experiment the translators so we can decide.
+1 to experimentation. Let's do this in a branch so we don't commit
ourselves to it?
> The biggest issues here are two:
>
> * Is the translated class debuggable? (Perhaps yes)
Yeah this is my biggest concern. If this is fine then I'm definately a +1.
> * Does the translator warn if unsupported API is used? (Perhaps no,
> but it's OK if we have enough unit tests.)
Also note that most 1.5 API can be downloaded as separate JSR modules
namely SASL jars but the user can download this. To maintain an API
agnostic character we still have to defensively code around then making
features optional if the right JDK is used or the API is present because
the user included the JSR JAR on the classpath.

Alex

Noel J. Bergman

2006-03-07, 5:45 pm

Enrique Rodriguez wrote:

> Noel J. Bergman wrote:
[vbcol=seagreen]
> FYI, we discussed this on 22-SEP-2005

> I've been looking forward to this for a while now.

Yes, and I am pointing out, again, that developers rush to new JDKs, whereas
customers upgrade much later; often *years* later.

> 1.5 has been out for over a year

And by 2008, I would expect to see most sites using it. Probably a
majority, but not overwhelmingly so, in 2007. What year is it now?

> In addition to SASL, we already require 1.5 for SSL in MINA and
> I, for one, would like to use some of the new concurrent
> collections and crypto.

So would I, but I'd also like to have people able and willing to use it.
What percentage of users would you like to use it? Separate standalone and
embedded deployments.

> Util-concurrent and newer crypto can be covered by other means, but I
> feel strongly about SASL.

On this we agree. But such benefits can often be obtained optionally, so
that the bulk of code does not require bleeding edge JDKs. If I want to use
MINA or ApacheDS on JDK 1.4, I would have to give up certain features, which
I gain by upgrading the JDK. That would be fine. For example, if we change
JAMES to use MINA and embed ApacheDS, I would not expect to be able to
support STARTTLS unless running on JDK 1.5.

--- Noel

Ole Ersoy

2006-03-07, 5:45 pm

+1 Here!

--- Trustin Lee <trustin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> On 3/7/06, Alex Karasulu <aok123-Bdlq13kUjeyLZ21kGMrzwg@public.gmane.org>
> wrote:
> 1.1 branch? 1.0 can
>
>
> Another big +1 here.

>
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP key fingerprints:
> * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
> * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
>

________________________________________
__________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Noel J. Bergman

2006-03-07, 5:45 pm

Alex Karasulu wrote:

> we still have to defensively code around then making features
> optional if the right JDK is used or the API is present because
> the user included the JSR JAR on the classpath.

With the benefit of giving users and embedding developers the most
flexibility and available features.

--- Noel

Emmanuel Lecharny

2006-03-07, 5:45 pm

Norbet Reilly a écrit :

>Thanks for the update on IBM's plans.
>
>Are you certain that WAS 6 is delivered with JDK1.5, that wasn't my
>expectation and a quick google showed up some people using WAS 6 and
>JDK1.4. Looking at
>http://www-306.ibm.com/software/web...v/was/features/ it
>seems it supports J2EE 1.4 (which Sun says needs JDK 1.5) but only JDK
>1.4, so presumably they're using some additional back-ported JDK1.5
>libraries but only the JDK1.4 JVM.
>
>Anyway, I know websphere support isn't most probably a pivotal issue
>for the AD development community, but I just trying to point out that
>mandating JDK1.5 at this point may cut you off from some otherwise
>keen customers - like me ;-)
>
>
>
Sorry about it, I've anticipated a little bit about the move of IBM
toward JDK 1.5

, Yeah, Websphere 6 will use 1.4.2, not 1.5 (we will
have to wait for 6.1, for sure, or 7.0, which is in diaper)

My bad !

From my point of view, I really don't care if we stick to 1.4. The only
thing I miss is Enum. But mina has some needs (mainly SSL) that could
lead it to produce two versions : one for 1.4 and another for 1.5.

At this point, it may be a little bit premature to decide if we have to
switch from 1.4 to 1.5 in ADS 1.1. We have a lot of time ! ADS 1.0 is
not even out, we still have to walk the line through 1.0-RC2, 1.0-RC3
etc... So there is no rush.

As usual, every six months, this question will be raised and this is a
*good* thing : real users will give their position, and we can think
about the real consequences of this switch basing our decision on real
cases, not just opinions

Call it democracy ...

Emmanuel Lécharny

Noel J. Bergman

2006-03-07, 5:45 pm

> From my point of view, I really don't care if we stick to 1.4. The only
> thing I miss is Enum. But mina has some needs (mainly SSL) that could
> lead it to produce two versions : one for 1.4 and another for 1.5.

What percentage of code needs to care? 1%? 5%? As much as 10% (highly
doubt that it is even close)?

The JDK 1.5 specific code can be isolated, and used selectively.

> As usual, every six months, this question will be raised and this is a
> *good* thing : real users will give their position, and we can think
> about the real consequences of this switch basing our decision on real
> cases, not just opinions

FWIW, we asked this question every 6 months to a year in JAMES for years,
and only recently did users say that we could drop support for 1.3.

--- Noel

Trustin Lee

2006-03-07, 5:45 pm

On 3/8/06, Noel J. Bergman <noel-3FWFAxrxNblBDgjK7y7TUQ@public.gmane.org> wrote:
>
>
> On this we agree. But such benefits can often be obtained optionally, so
> that the bulk of code does not require bleeding edge JDKs. If I want to
> use
> MINA or ApacheDS on JDK 1.4, I would have to give up certain features,
> which
> I gain by upgrading the JDK. That would be fine. For example, if we
> change
> JAMES to use MINA and embed ApacheDS, I would not expect to be able to
> support STARTTLS unless running on JDK 1.5.

I agree with you all ApacheDS and MINA users should be able to use them on
JDK 1.4. My idea is to enable backward compatibility using bytecode
manipulator which is a reasonable solution so the requirement remains the
same and we can use advanced language features like generics and covariant
return types yet. These language features help us to program more
effectively and users to use cleaner API if they use the API on Java 5.
We'll also have to be careful not to expose unsafe collections and APIs
without backward compatibility where user and our software interacts, but
it's just another matter.

Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6

Ceki Gülcü

2006-03-09, 5:45 pm

I tried to summarize some of the arguments given here in my blog (see=20
below). In a nutshell, aiming for JDK 1.4 compatibility using JDK 1.5=20
language features is likely to be messy, especially if you accept patches=20
from "outside" developers. On the other hand, who would blame you to want=20
to switch to JDK 1.5 when JDK 1.6 is in the offing?

Cheers,

At 12:28 AM 3/8/2006, Trustin Lee wrote:
>I agree with you all ApacheDS and MINA users should be able to use them on=
=20
>JDK 1.4. My idea is to enable backward compatibility using bytecode=20
>manipulator which is a reasonable solution so the requirement remains the=
=20
>same and we can use advanced language features like generics and covariant=
=20
>return types yet. These language features help us to program more=20
>effectively and users to use cleaner API if they use the API on Java=20
>5. We'll also have to be careful not to expose unsafe collections and=20
>APIs without backward compatibility where user and our software interacts,=
=20
>but it's just another matter.
>
>Trustin
>--

--=20
Ceki G=FClc=FC
http://ceki.blogspot.com/

Noel J. Bergman

2006-03-09, 5:45 pm

> who would blame you to want to switch to JDK 1.5 when
> JDK 1.6 is in the offing?

To quote your own blog: "However, recent reports claim that only 20% of
users have switched to JDK 1.5, with 20% still using JDK 1.3, and the
remaining 60% JDK 1.4."

So assuming those figures to be accurate (from where did they come?), would
we want to limit the potential base to 25% of what it would be were we to
support the vast bulk of the market?

--- Noel

Ceki Gülcü

2006-03-09, 5:45 pm

At 08:26 PM 3/9/2006, Noel J. Bergman wrote:

>To quote your own blog: "However, recent reports claim that only 20% of
>users have switched to JDK 1.5, with 20% still using JDK 1.3, and the
>remaining 60% JDK 1.4."
>
>So assuming those figures to be accurate (from where did they come?), would
>we want to limit the potential base to 25% of what it would be were we to
>support the vast bulk of the market?

The JDK market figures were reported in an article I read on TSS. They=20
sound quite plausible but I can't vouch for their reliability,

A friend recently told me that the entire development effort of his company=
=20
was based on C++ because a required statistical library was available only=
=20
in C++. I am mentioning this because if a given library is a requirement,=20
then clients will find ways of using/supporting it. This is certainly true=
=20
if the product is standalone. After all JDK 1.5 is available on most=20
platforms and installing it is not an issue. As for embedded mode, maybe=20
Geronimo could still embed it. In log4j for example, we support a few=20
libraries requiring JDK 1.4, whereas log4j itself could be compiled and run=
=20
using JDK 1.2 (except of course those libs requiring later JDKS). Geronimo=
=20
folks probably already know how to deal with such issues. Does anyone know=
=20
if they have an opinion on the subject?

Just my unsolicited 2c.

--=20
Ceki G=FClc=FC
http://ceki.blogspot.com/

Trustin Lee

2006-03-09, 8:45 pm

On 3/10/06, Ceki Gülcü <listid-vdLmLxQ6Fys@public.gmane.org> wrote:
>
>
> I tried to summarize some of the arguments given here in my blog (see
> below). In a nutshell, aiming for JDK 1.4 compatibility using JDK 1.5
> language features is likely to be messy, especially if you accept patches
> from "outside" developers. On the other hand, who would blame you to want
> to switch to JDK 1.5 when JDK 1.6 is in the offing?

I'd like to say maintaining the backward compatibiliy can become messy just
because of the lack of the feature in retrotranslator, not because of the
techinique itself. If retrotranslator builds an API dictionary which
contains the API difference between JDK 1.4 and 1.5, then we can return an
error while translation very easily without much cost. Actually, I want to
contribute this feature to the retrotranslator team.

Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6

Emmanuel Lecharny

2006-03-09, 8:45 pm

Noel J. Bergman a écrit :

>To quote your own blog: "However, recent reports claim that only 20% of
>users have switched to JDK 1.5, with 20% still using JDK 1.3, and the
>remaining 60% JDK 1.4."
>
>
Well, as everybody knows, a statistic reported that 57.4% of statistics
are plain wrong...

>So assuming those figures to be accurate (from where did they come?), would
>we want to limit the potential base to 25% of what it would be were we to
>support the vast bulk of the market?
>
>
Are we talking about those extra 5% users above 100% ?

At this point, what will be usefull instead of challenging tools like
retrowhatever to do the 1.5 -> 1.4 work for us is to list features that
need 1.5 to be implemented. Then we may isolate them in libraries beside
the server itself, and :
- tell the users that they need a 1.5 JVM to use these features
- or use retrosatanas to allow 1.4 users to benefit from these features.

I must admit that for ADS core and shared-ldap parts, we don't need 1.5,
from a technical point of view (Alex, correct me if I'm wrong). If 1.5
is needed for SSL, I don't think that switching to 1.5 for this very
specific part to be a problem, because using SSL means that the server
is not embeded, and then run as a standalone service.

I don't know about Kerberos...

wdyt ?

Emmanuel

Enrique Rodriguez

2006-03-09, 8:45 pm

Emmanuel Lecharny wrote:
....
> I don't know about Kerberos...

Kerberos doesn't need 1.5. Though, using 1.5 would make more advanced
encryption types available.

To use Kerberos auth with the LDAP wire protocol requires SASL.

Enrique

Emmanuel Lecharny

2006-03-09, 8:45 pm

Enrique Rodriguez a écrit :

> Emmanuel Lecharny wrote:
> ...
>
>
>
> Kerberos doesn't need 1.5. Though, using 1.5 would make more advanced
> encryption types available.
>
> To use Kerberos auth with the LDAP wire protocol requires SASL.
>
> Enrique
>
But then will this means that ADS with SASL will be a standalone server,
or can it be embedded ?

Emmanuel

Enrique Rodriguez

2006-03-09, 8:45 pm

Emmanuel Lecharny wrote:
....
> But then will this means that ADS with SASL will be a standalone server,
> or can it be embedded ?

Based on past discussions, we thought that SASL could be implemented as
a MINA filter. If so, the same restrictions as the SSL filter would apply.

Enrique

Emmanuel Lecharny

2006-03-09, 8:45 pm

Enrique Rodriguez a écrit :

> Emmanuel Lecharny wrote:
> ...
>
>
>
> Based on past discussions, we thought that SASL could be implemented
> as a MINA filter. If so, the same restrictions as the SSL filter
> would apply.
>
> Enrique
>
ok, so that means we can go for a 1.5 version if we need SSL and if SSL
is implemented as a MINA filter, as the server won't be embeded.

We only need to have a 1.4 compatible MINA + 1.5 SSL library filter for
users who want it (ADS will remain 1.4), and the World will be happy, is
that it?

Emmanuel

Ole Ersoy

2006-03-10, 2:45 am

Hey Guys,

Just a general thoughts from following along in the
conversations.

I would think that one of the primary considerations
for 1.5 would be "real world" people/organizations
writing in to this mailing list and saying something
to the effect of "Please stay with 1.4, because we
have the following support requirements...."

So far there seems to be very limited objection to
1.5, and mostly in favor of votes.

So what about looking at it like this:

When is the 1.1 branch going to be production ready?
- If we stick with 1.4?
- If we go with 1.5?

Suppose it's 4 months.

That gives someone who's seriously considering
embedding apache ds 4 months to upgrade the embedding
application.

That's for people who are aware of apache ds and
seriously needing to embed it. So far there has not
really been an outcry from those users.

So suppose that's because the RC1 candidate just got
released...and users really have not gotten their
hands on the red hot potato and started to spread the
word.

Suppose that happends 6 months from now and a lot of
organizations start embedding / using it.

Out of all the users how many really need to embed it?

Can't they just run it in a separate jvm until they
upgrade the code to 1.5 and embed away..../...what are
the use cases that absolutely require the server to be
embedded?

I figured since we were looking at statistics and such
it might help to say something like...ok suppose 50%
of the market is running jvm 1.4 in their apps when
1.1 is ready with 1.5? Out of that 50% how many need
to / want to embed apache ds? Does there exist a use
case where someone absolutely has to embed it or can
they get around it until they upgrade the embedding
code to 1.5?

One consideration for answering that is that the
people doing the embedding have to be relatively solid
software engineers, creating a fairly unique product.
If the are smart enough to do that, I would think that
they would be sharp enough to rapidly upgrade their
code.

Just guessing I would think that 90%-95% are
organizations that need a directory server for
traditional authentication and authorization / mail
address lookup type stuff...

Just some thoughts.

Cheers,
- Ole

--- Enrique Rodriguez <enriquer9-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> Emmanuel Lecharny wrote:
> ...
>
> Kerberos doesn't need 1.5. Though, using 1.5 would
> make more advanced
> encryption types available.
>
> To use Kerberos auth with the LDAP wire protocol
> requires SASL.
>
> Enrique
>

________________________________________
__________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Noel J. Bergman

2006-03-10, 2:45 am

Emmanuel Lecharny wrote:

> Noel J. Bergman a écrit :
[vbcol=seagreen]
[vbcol=seagreen]
> Are we talking about those extra 5% users above 100% ?

No ... discounting the 20% who are using JDK 1.3 leaves us with 80% who are
using JDK 1.4 or later. Users of JDK 1.5 are 25% of that figure, whereas
JDK 1.4 users represent 75%, and users of JDK 1.3 and earlier are no longer
included.

> what will be useful [is] is to list features that need 1.5
> to be implemented. Then we may isolate them

Agreed.

> I must admit that for ADS core and shared-ldap parts, we don't need 1.5,
> from a technical point of view (Alex, correct me if I'm wrong).

I would agree. MINA is where the dependences arise, and there are certain
features that can fairly be labeled as requiring JDK 1.5.

--- Noel

Noel J. Bergman

2006-03-10, 2:45 am

> I would think that one of the primary considerations
> for 1.5 would be "real world" people/organizations
> writing in to this mailing list

So far, I'm not sure how many exist.

> That gives someone who's seriously considering
> embedding apache ds 4 months to upgrade the
> embedding application.

Keep in mind that, according to Ceki's figures, as many people are still
using JDK 1.3 today as are using JDK 1.5. Developers tend to have a totally
whacked view of how long customers actually take to evolve platform
technology.

--- Noel

Ole Ersoy

2006-03-10, 2:45 am

I agree on the wacked view.

I'm sitting here enjoying some Asahi, and it's getting
more and more out of focus by the minute.

What I'm trying to zoom in on though is the population
of developers needing to embed the Apache DS.

I think one could make the following assumptions:
- The population of developers needing to embed
ApacheDS are large organizations like IBM, BEA, etc.

- The developers that are doing the embedding are very
sharp...sort of like the people who made ApacheDS...ok
maybe not that sharp...

- Given the first two assumptions, the population
could easily get around any 1.5 constraints, and then
go have some Asahi!

Oh Oh - Glass is almost empty. Gotta go get refilled.

Cheers,
- Ole

--- "Noel J. Bergman" <noel-3FWFAxrxNblBDgjK7y7TUQ@public.gmane.org> wrote:

> considerations
>
> So far, I'm not sure how many exist.
>
>
> Keep in mind that, according to Ceki's figures, as
> many people are still
> using JDK 1.3 today as are using JDK 1.5.
> Developers tend to have a totally
> whacked view of how long customers actually take to
> evolve platform
> technology.
>
> --- Noel
>
>

________________________________________
__________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Alex Karasulu

2006-03-10, 5:45 pm

Emmanuel Lecharny wrote:
>
> I must admit that for ADS core and shared-ldap parts, we don't need
> 1.5, from a technical point of view (Alex, correct me if I'm wrong).

You are right on Emmanuel!

Alex

Alex Karasulu

2006-03-10, 5:45 pm

Enrique Rodriguez wrote:
> Emmanuel Lecharny wrote:
> ...
>
> Kerberos doesn't need 1.5. Though, using 1.5 would make more advanced
> encryption types available.
>
> To use Kerberos auth with the LDAP wire protocol requires SASL.
And SASL would best work with JDK 1.5 although we could make it an
optional feature. I have many opinions here prepare for a long email to
try to clarify this situation

.

Alex

Alex Karasulu

2006-03-10, 5:45 pm

I was going to write a long email about this but let me condense it.

(1) JDK 1.4 and up is supported for all user types (including embedding
users) in 1.0 branch and this will never change. This branch is alive
and well and will be maintained with bug fixes. There already are
features in this branch that are 1.5 specific and you can get those by
adding some extra "components" but must run them on JDK 1.5 (SSL is the
only JDK 1.5 requirement at this point).

(2) The 1.1 branch is an experimental/feature addition branch. Even
Geronimo will not look back and will use JDK 1.5 for there latest
development branch. Does this mean we have to? Not necessarily. This
branch will most likely add compliance with OpenGroup. It will also
introduce enhancements for performance in the database, DN handling and
in the asn1 subsystems. This branch will release often hopefully but
that does not mean users should use it. The real culmination of this
branch will be the stable release of 1.2. This will take 4-6 months at
a minimum. In that time more users will be on JDK 1.5 but we will still
have most users on 1.4.

(3) A clean break is always better than a half assed job period.
However we need to get our timing straight. That's all this JDK
discussion is really about. So we have to pick just when we make this jump.

So now here's my opinion:

(a) MINA sticks to 1.4 support without messing with byte code and
experiments with retroweaver. She should release a 1.0 and have a solid
stable API for 1.4 and 1.5 support. At this point I'd like to see mina
graduate incubation and start a new branch 1.1 which focuses on JDK1.5
with mina 1.0 as 1.4 fall back. This can occur in about 4-6 months IMHO.

(b) ApacheDS sticks to 1.4 support in the 1.1 and 1.2 branches. For 1.5
needs it juggles new components and leverages OSGi to help manage this.
SASL, SSL, Crypto libs and other features that may need 1.5 can load 1.5
specific bundles to do this. This sucks and is going to be a pita for
us the developers but we can do it and we have OSGi to help. At this
point 1.0 dies and 1.2 becomes the main supported branch.

(c) Once MINA graduates and starts work on a pure JDK 1.5+ branch we can
start a new experimental branch for ApacheDS, branch 1.5 skipping 1.3
altogether. Here we redesign the server to use all 1.5 features. The
design/architecture and readability, maintainability greatly improves.
We then bump up the GA release branch to 2.0. This is a year out in the
making. Plus it will coincide with mina 1.1 or whatever we choose it to
be designated as for jdk 1.5 support. At this point we can decide to
kill 1.2 or to keep on supporting bug fixes in it for 6 more months
(recommended) until SUN puts an EOL on jdk 1.4.

Summary
=======

(1) Users are happy, embedding and standalone users
(2) Developers deal with the burden but use OSGi to alleviate the pain
(3) We have a clean manageable break which will make life bearable
(4) MINA progresses forward with 1.0 and 1.1 jdk 5 support with a nice
clean break and gets a new home as it should
(5) ApacheDS 1.2 will pretty much have the same functionality as 2.0 so
there will be little complains. The server will just be redesigned to
make it easier for developers. There is only so much you can do with
LDAP, DNS and Kerberos.

DHCP is another story but we can talk later about this one.

Heh we can deal later with these headaches 1.6 will bring a year from now.

Cheers,
Alex

P.S. Can we agree on this and forge ahead please?

peter royal

2006-03-10, 5:45 pm

Trustin Lee

2006-03-10, 5:45 pm

On 3/11/06, Alex Karasulu <aok123-Bdlq13kUjeyLZ21kGMrzwg@public.gmane.org> wrote:
>
> (a) MINA sticks to 1.4 support without messing with byte code and
> experiments with retroweaver. She should release a 1.0 and have a solid
> stable API for 1.4 and 1.5 support. At this point I'd like to see mina
> graduate incubation and start a new branch 1.1 which focuses on JDK1.5
> with mina 1.0 as 1.4 fall back. This can occur in about 4-6 months IMHO.

If MINA is released with 1.4 and 1.5 support not using retrotranslator, we
have to maintain two branches for one release. Do you mean it? I have done
it before with other projects and it was a real overhead.

BTW it is very strange that nobody responses to my messages about
retrotranslator (not retroweaver). I want to listen to any reason behind
all other people's opinions with respect to my opinion.

Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6

peter royal

2006-03-10, 5:45 pm

Trustin Lee

2006-03-10, 8:45 pm

On 3/11/06, peter royal <proyal-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
>
> On Mar 10, 2006, at 6:18 PM, Trustin Lee wrote:
>
> On 3/11/06, Alex Karasulu <aok123-Bdlq13kUjeyLZ21kGMrzwg@public.gmane.org> wrote:
>
>
> If MINA is released with 1.4 and 1.5 support not using retrotranslator, we
> have to maintain two branches for one release. Do you mean it? I have done
> it before with other projects and it was a real overhead.
>
>
> I think Alex means that Mina 1.0 wouldn't use any 1.5-specific features.
>

If so, it's fine.

BTW it is very strange that nobody responses to my messages about
> retrotranslator (not retroweaver). I want to listen to any reason behind
> all other people's opinions with respect to my opinion.
>
>
> I'm fine with retrotranslater, but only because I wouldn't be using it in
> any production systems

I totally understand the concerns of people about
> using bytecode modification in production systems.
>

I think it doesn't have much difference from AOP or runtime bytecode
generation which is used by modern frameworks such as Hibernate and
Springframework. So I guess it is just because we didn't experience
retrotranslator enough. Considering its internal translation mechanism, it
is almost 1-to-1 translation via a translation dictionary, which should be
quite safe.

Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6

Alex Karasulu

2006-03-10, 8:45 pm

Trustin Lee wrote:
>
>
> On 3/11/06, *peter royal* <proyal-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org
> <mailto:proyal-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org>> wrote:
>
> On Mar 10, 2006, at 6:18 PM, Trustin Lee wrote:
>
>
> I think Alex means that Mina 1.0 wouldn't use any 1.5-specific
> features.
>
>
> If so, it's fine.

>
>
> I'm fine with retrotranslater, but only because I wouldn't be
> using it in any production systems

I totally understand the
> concerns of people about using bytecode modification in production
> systems.
>
>
> I think it doesn't have much difference from AOP or runtime bytecode
> generation which is used by modern frameworks such as Hibernate and
> Springframework. So I guess it is just because we didn't experience
> retrotranslator enough. Considering its internal translation
> mechanism, it is almost 1-to-1 translation via a translation
> dictionary, which should be quite safe.
Trustin I'm really uneasy with anything that manipulates byte code or
source code auto-magically. It think making a clean split somewhere is
much easier than wondering WTF happened when crazy things start
happening. Ruling out the retro-xxx facility gives me a level of
confidence that I screwed something up and should keep searching for
something in my code.

Why the push to 1.5 now with retro-xxx can't we release a MINA 1.0
without 1.5?

Alex