You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Stojce Dimski <sd...@yahoo.it> on 2007/11/13 15:52:31 UTC
requirements, dependencies, jdk...
Do you people have considered moving code to Java 5 and maybe using
something like this http://retrotranslator.sourceforge.net/ for
backward compatibility for Java 1.4/1.3 ? There is even a maven plugin
;-)
Some small dependency as
http://backport-jsr166.sourceforge.net/index.php could bring benefits
of java.util.concurrent...
Many many users which use Java 5/6 will have not even one dependency...
What is the reason to remain on 1.3, and religious refuse to any
dependency ?
There are http://code.google.com/p/google-collections/ which will
probably become a part of Java7, have a look:
http://publicobject.com/2007/09/series-recap-coding-in-small-with.html
and tell me if this is of no use and benefit...
Maybe some small compromise could benefit greatly, WDYT ?
___________________________________
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: requirements, dependencies, jdk...
Posted by Stojce Dimski <sd...@yahoo.it>.
--- Oleg Kalnichevski <ol...@apache.org> ha scritto:
>
> On Tue, 2007-11-13 at 15:52 +0100, Stojce Dimski wrote:
> > Do you people have considered moving code to Java 5 and maybe using
> > something like this http://retrotranslator.sourceforge.net/ for
> > backward compatibility for Java 1.4/1.3 ? There is even a maven
> plugin
> > ;-)
> > Some small dependency as
> > http://backport-jsr166.sourceforge.net/index.php could bring
> benefits
> > of java.util.concurrent...
> > Many many users which use Java 5/6 will have not even one
> dependency...
> > What is the reason to remain on 1.3, and religious refuse to any
> > dependency ?
> > There are http://code.google.com/p/google-collections/ which will
> > probably become a part of Java7, have a look:
> >
>
http://publicobject.com/2007/09/series-recap-coding-in-small-with.html
> > and tell me if this is of no use and benefit...
> > Maybe some small compromise could benefit greatly, WDYT ?
> >
> >
>
> Hi Stojce
>
> Here's my personal take on this issue
>
> (1) Initially the main reason for 1.3 compatibility was easy
> portability
> to Java Micro Edition. Now, as Sun is believed to be considering
> deprecating JME in favor of straight JSE, 1.3 compatibility may no
> longer be of any practical value, but 1.4 compatibility may still
> prove
> useful.
>
> (2) HttpCore is meant to be used at the very bottom of a complex
> component stack. The use of external dependencies has unpleasant
> implication of forcing the user into transitive dependency on a
> _specific_ version of those dependencies. The more transitive
> dependencies there are, the higher are the chances of running into a
> version conflict. Low level libraries such as HttpCore ought not have
> external dependencies if they want to play nicely with other
> libraries.
>
> HttpCore is currently a more mature set of components in
> HttpComponents,
> but in future its importance will lessen as there will be other
> higher
> level components built on top of it such as HttpClient, which are
> more
> suitable for end users. We can certainly be much less restrictive
> about
> JRE compatibility requirement and the use of external dependencies
> for
> those components.
>
> I personally would favor upgrading HttpClient 4.0 to Java 1.5, for
> instance. It is still not too late.
>
> Oleg
>
>
> > ___________________________________
> > L'email della prossima generazione? Puoi averla con la nuova Yahoo!
> Mail: http://it.docs.yahoo.com/nowyoucan.html
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> httpcomponents-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> httpcomponents-dev-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> httpcomponents-dev-help@jakarta.apache.org
>
>
___________________________________
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: requirements, dependencies, jdk...
Posted by Stojce Dimski <sd...@yahoo.it>.
--- Oleg Kalnichevski <ol...@apache.org> ha scritto:
>
> On Tue, 2007-11-13 at 15:52 +0100, Stojce Dimski wrote:
> > Do you people have considered moving code to Java 5 and maybe using
> > something like this http://retrotranslator.sourceforge.net/ for
> > backward compatibility for Java 1.4/1.3 ? There is even a maven
> plugin
> > ;-)
> > Some small dependency as
> > http://backport-jsr166.sourceforge.net/index.php could bring
> benefits
> > of java.util.concurrent...
> > Many many users which use Java 5/6 will have not even one
> dependency...
> > What is the reason to remain on 1.3, and religious refuse to any
> > dependency ?
> > There are http://code.google.com/p/google-collections/ which will
> > probably become a part of Java7, have a look:
> >
>
http://publicobject.com/2007/09/series-recap-coding-in-small-with.html
> > and tell me if this is of no use and benefit...
> > Maybe some small compromise could benefit greatly, WDYT ?
> >
> >
>
> Hi Stojce
>
> Here's my personal take on this issue
>
> (1) Initially the main reason for 1.3 compatibility was easy
> portability
> to Java Micro Edition. Now, as Sun is believed to be considering
> deprecating JME in favor of straight JSE, 1.3 compatibility may no
> longer be of any practical value, but 1.4 compatibility may still
> prove
> useful.
>
> (2) HttpCore is meant to be used at the very bottom of a complex
> component stack. The use of external dependencies has unpleasant
> implication of forcing the user into transitive dependency on a
> _specific_ version of those dependencies. The more transitive
> dependencies there are, the higher are the chances of running into a
> version conflict. Low level libraries such as HttpCore ought not have
> external dependencies if they want to play nicely with other
> libraries.
>
> HttpCore is currently a more mature set of components in
> HttpComponents,
> but in future its importance will lessen as there will be other
> higher
> level components built on top of it such as HttpClient, which are
> more
> suitable for end users. We can certainly be much less restrictive
> about
> JRE compatibility requirement and the use of external dependencies
> for
> those components.
>
> I personally would favor upgrading HttpClient 4.0 to Java 1.5, for
> instance. It is still not too late.
>
> Oleg
>
>
> > ___________________________________
> > L'email della prossima generazione? Puoi averla con la nuova Yahoo!
> Mail: http://it.docs.yahoo.com/nowyoucan.html
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> httpcomponents-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> httpcomponents-dev-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> httpcomponents-dev-help@jakarta.apache.org
>
>
___________________________________
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: requirements, dependencies, jdk...
Posted by Tatu Saloranta <co...@yahoo.com>.
--- Oleg Kalnichevski <ol...@apache.org> wrote:
> On Tue, 2007-11-13 at 15:52 +0100, Stojce Dimski
> wrote:
> > Do you people have considered moving code to Java
> 5 and maybe using
...
> Hi Stojce
>
> Here's my personal take on this issue
>
...
> (2) HttpCore is meant to be used at the very bottom
> of a complex
> component stack. The use of external dependencies
> has unpleasant
...
> HttpCore is currently a more mature set of
> components in HttpComponents,
> but in future its importance will lessen as there
> will be other higher
> level components built on top of it such as
> HttpClient, which are more
...
> I personally would favor upgrading HttpClient 4.0 to
> Java 1.5, for
> instance. It is still not too late.
I fully agree. Although I would not be dead set
against 1.5, I would prefer that higher-level parts
require it first, i.e. HttpClient, and that as long as
there's nothing fundamentally required, core parts for
4.0 would only require 1.4.
-+ Tatu +-
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: requirements, dependencies, jdk...
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2007-11-14 at 13:38 +0100, Ortwin Glück wrote:
>
> Oleg Kalnichevski wrote:
> > (2) We do have some home-baked concurrency primitives in HttpCore NIO,
> > but none of them is exposed in the public API. The potential reduction
> > of custom code does not seem significant enough to justify the change of
> > minimal JRE level just a couple of weeks before the API freeze.
>
> Synchronization that can be avoided with stuff from the concurrent
> package? (Not because of performance, but because of the danger of
> unforseen deadlocks.)
>
The I/O reactor code is fairly simple from the synchronization
standpoint. Really complex stuff usually happens at the protocol
handling level and is supposed to be outside Core anyways.
Someone (preferably not me, because I can be biased) should take a fresh
look at the HttpCore NIO and decide whether the use of j.u.concurrent
would result in significant code improvements.
Cheers
Oleg
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: requirements, dependencies, jdk...
Posted by Ortwin Glück <od...@odi.ch>.
Oleg Kalnichevski wrote:
> (2) We do have some home-baked concurrency primitives in HttpCore NIO,
> but none of them is exposed in the public API. The potential reduction
> of custom code does not seem significant enough to justify the change of
> minimal JRE level just a couple of weeks before the API freeze.
Synchronization that can be avoided with stuff from the concurrent
package? (Not because of performance, but because of the danger of
unforseen deadlocks.)
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: requirements, dependencies, jdk...
Posted by Ortwin Glück <od...@odi.ch>.
Oleg Kalnichevski wrote:
> Guys,
>
> By the time HttpClient 4.0 goes final, we can expect Java 1.5 JRE to be
> very widely deployed. Besides, for those who are unfortunate enough to
> be stuck with 1.4 JRE there is always HttpCore and HttpClient 3.1. Even
> Websphere runs on Java 1.5 these days.
>
> Oleg
In J2EE servers you can also do a lot of classloader magic, so you could
use multiple incompatible versions of HttpClient within the same
container. Fine for me.
--
[web] http://www.odi.ch/
[blog] http://www.odi.ch/weblog/
[pgp] key 0x81CF3416
finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: requirements, dependencies, jdk...
Posted by Tatu Saloranta <co...@yahoo.com>.
--- Oleg Kalnichevski <ol...@apache.org> wrote:
...
> > JBoss ships with HttpClient by default. Don't know
> exactly what they use
> > it for, but I guess for webservices. Also all of
> our J2EE applications
> > use HttpClient. I think it is very important not
> to cause dependency hell.
But could it be the case that since scope of
httpclient-4.0 will be much smaller than that of
3.0's, that they could perhaps just use httpcore-4.0,
which wouldn't require 1.5? I mean, assuming they know
what they are doing, and what it's being used for.
Regarding 1.5, I agree in that generics is usually not
a big deal for low-level libraries (certainly nice to
have, but not must to have). But what I have learnt to
like a lot are enums -- they are very useful for clean
APIs; efficient to use (like int values), have more
semantic info, can have helper methods.
So that has been high on my list for wanting to go to
1.5 for those projects that are not quite as low down
the stack as httpclient.
-+ Tatu +-
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: requirements, dependencies, jdk...
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2007-11-14 at 13:56 +0100, Ortwin Glück wrote:
> sebb wrote:
> > I think this depends on where HttpClient is likely to be used. If it
> > is extensively used in large applications such as servers etc - which
> > may depend on lots of other software - then it seems to me that
> > HttpClient should only require 1.5 if that is absolutely necessary at
> > run-time.
>
> JBoss ships with HttpClient by default. Don't know exactly what they use
> it for, but I guess for webservices. Also all of our J2EE applications
> use HttpClient. I think it is very important not to cause dependency hell.
>
>
Guys,
By the time HttpClient 4.0 goes final, we can expect Java 1.5 JRE to be
very widely deployed. Besides, for those who are unfortunate enough to
be stuck with 1.4 JRE there is always HttpCore and HttpClient 3.1. Even
Websphere runs on Java 1.5 these days.
Oleg
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: requirements, dependencies, jdk...
Posted by Ortwin Glück <od...@odi.ch>.
sebb wrote:
> I think this depends on where HttpClient is likely to be used. If it
> is extensively used in large applications such as servers etc - which
> may depend on lots of other software - then it seems to me that
> HttpClient should only require 1.5 if that is absolutely necessary at
> run-time.
JBoss ships with HttpClient by default. Don't know exactly what they use
it for, but I guess for webservices. Also all of our J2EE applications
use HttpClient. I think it is very important not to cause dependency hell.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: requirements, dependencies, jdk...
Posted by sebb <se...@gmail.com>.
On 14/11/2007, Oleg Kalnichevski <ol...@apache.org> wrote:
>
> On Tue, 2007-11-13 at 17:23 +0100, Stojce Dimski wrote:
> > Hi Oleg,
> >
> > Updating the source code to use Java5 will bring no external
> > dependencies...
> > Using Backport of (java.util.concurrent) will bring just one single
> > dependency in one single case (Java 1.4 platform) in other cases (Java
> > 5,6,7) there are no dependencies... As this library is very much used
> > in many projects the 'version conflict' you have mentioned is mainly
> > theoretical...
> > I admit that 'google-collections' case is maybe dependency 'too much'
> > but Java5 source code baseline and Backport are very worth the trouble
> > ;-) WDYT ?
> >
> > P.S. sorry for the previous message a click-too-much...
> >
> > Cheers,
> > Stojce
> >
>
> Hi Stojce
>
> I personally do not see a very convincing case for moving HttpCore to
> Java 1.5. There are two features that make Java 1.5 appealing to me:
> generics and j.u.concurrent.
>
> HttpCore base
> =============
> (1) I do not see what interfaces could benefit from the use of generics.
> We are not using collection interfaces at all.
> (2) We do not have _any_ threading code in HttpCore base, so
> j.u.concurrent will not be of any use.
>
> HttpCore NIO
> =============
> (1) Same here. Do not see what interfaces could benefit from generics.
> (2) We do have some home-baked concurrency primitives in HttpCore NIO,
> but none of them is exposed in the public API. The potential reduction
> of custom code does not seem significant enough to justify the change of
> minimal JRE level just a couple of weeks before the API freeze.
>
> HttpCore NIOSSL
> =============
> Requires Java 1.5 already
>
> To sum things up, I personally do not see a very strong case for moving
> HttpCore to Java 1.5. I am quite in favor of moving HttpClient to Java
> 1.5, though.
I think this depends on where HttpClient is likely to be used. If it
is extensively used in large applications such as servers etc - which
may depend on lots of other software - then it seems to me that
HttpClient should only require 1.5 if that is absolutely necessary at
run-time.
However if HttpClient is only used in stand-alone applications (e.g.
JMeter), then it will normally be easier for the user to upgrade to
1.5. But even here, it's important that the required level of Java is
readily available - it's going to annoy users if they have to install
1.5 just to run the application.
> Cheers,
>
> Oleg
>
>
>
>
>
>
>
> >
> >
> > ___________________________________
> > L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: requirements, dependencies, jdk...
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2007-11-13 at 17:23 +0100, Stojce Dimski wrote:
> Hi Oleg,
>
> Updating the source code to use Java5 will bring no external
> dependencies...
> Using Backport of (java.util.concurrent) will bring just one single
> dependency in one single case (Java 1.4 platform) in other cases (Java
> 5,6,7) there are no dependencies... As this library is very much used
> in many projects the 'version conflict' you have mentioned is mainly
> theoretical...
> I admit that 'google-collections' case is maybe dependency 'too much'
> but Java5 source code baseline and Backport are very worth the trouble
> ;-) WDYT ?
>
> P.S. sorry for the previous message a click-too-much...
>
> Cheers,
> Stojce
>
Hi Stojce
I personally do not see a very convincing case for moving HttpCore to
Java 1.5. There are two features that make Java 1.5 appealing to me:
generics and j.u.concurrent.
HttpCore base
=============
(1) I do not see what interfaces could benefit from the use of generics.
We are not using collection interfaces at all.
(2) We do not have _any_ threading code in HttpCore base, so
j.u.concurrent will not be of any use.
HttpCore NIO
=============
(1) Same here. Do not see what interfaces could benefit from generics.
(2) We do have some home-baked concurrency primitives in HttpCore NIO,
but none of them is exposed in the public API. The potential reduction
of custom code does not seem significant enough to justify the change of
minimal JRE level just a couple of weeks before the API freeze.
HttpCore NIOSSL
=============
Requires Java 1.5 already
To sum things up, I personally do not see a very strong case for moving
HttpCore to Java 1.5. I am quite in favor of moving HttpClient to Java
1.5, though.
Cheers,
Oleg
>
>
> ___________________________________
> L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: requirements, dependencies, jdk...
Posted by Stojce Dimski <sd...@yahoo.it>.
Hi Oleg,
Updating the source code to use Java5 will bring no external
dependencies...
Using Backport of (java.util.concurrent) will bring just one single
dependency in one single case (Java 1.4 platform) in other cases (Java
5,6,7) there are no dependencies... As this library is very much used
in many projects the 'version conflict' you have mentioned is mainly
theoretical...
I admit that 'google-collections' case is maybe dependency 'too much'
but Java5 source code baseline and Backport are very worth the trouble
;-) WDYT ?
P.S. sorry for the previous message a click-too-much...
Cheers,
Stojce
___________________________________
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: requirements, dependencies, jdk...
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2007-11-13 at 15:52 +0100, Stojce Dimski wrote:
> Do you people have considered moving code to Java 5 and maybe using
> something like this http://retrotranslator.sourceforge.net/ for
> backward compatibility for Java 1.4/1.3 ? There is even a maven plugin
> ;-)
> Some small dependency as
> http://backport-jsr166.sourceforge.net/index.php could bring benefits
> of java.util.concurrent...
> Many many users which use Java 5/6 will have not even one dependency...
> What is the reason to remain on 1.3, and religious refuse to any
> dependency ?
> There are http://code.google.com/p/google-collections/ which will
> probably become a part of Java7, have a look:
> http://publicobject.com/2007/09/series-recap-coding-in-small-with.html
> and tell me if this is of no use and benefit...
> Maybe some small compromise could benefit greatly, WDYT ?
>
>
Hi Stojce
Here's my personal take on this issue
(1) Initially the main reason for 1.3 compatibility was easy portability
to Java Micro Edition. Now, as Sun is believed to be considering
deprecating JME in favor of straight JSE, 1.3 compatibility may no
longer be of any practical value, but 1.4 compatibility may still prove
useful.
(2) HttpCore is meant to be used at the very bottom of a complex
component stack. The use of external dependencies has unpleasant
implication of forcing the user into transitive dependency on a
_specific_ version of those dependencies. The more transitive
dependencies there are, the higher are the chances of running into a
version conflict. Low level libraries such as HttpCore ought not have
external dependencies if they want to play nicely with other libraries.
HttpCore is currently a more mature set of components in HttpComponents,
but in future its importance will lessen as there will be other higher
level components built on top of it such as HttpClient, which are more
suitable for end users. We can certainly be much less restrictive about
JRE compatibility requirement and the use of external dependencies for
those components.
I personally would favor upgrading HttpClient 4.0 to Java 1.5, for
instance. It is still not too late.
Oleg
> ___________________________________
> L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: requirements, dependencies, jdk...
Posted by sebb <se...@gmail.com>.
On 15/11/2007, Oleg Kalnichevski <ol...@apache.org> wrote:
> sebb wrote:
> > On 15/11/2007, Oleg Kalnichevski <ol...@apache.org> wrote:
> >> Roland Weber wrote:
> >>> Hi all,
> >>>
> >>> I also think that changing the JDK requirement for HttpCore
> >>> between the last alpha and first beta would be a case of
> >>> very poor timing. Even if 1.3 compatibility becomes obsolete,
> >>> there will always be mobile devices where the full J2SE is
> >>> not available. We can reconsider the minimum requirements
> >>> for HttpCore 4.1.
> >>>
> >>> For HttpClient, I don't care about the minimum JDK level,
> >>> as long as you don't expect me to learn Java 5 over night :-)
> >>>
> >> Hi Roland
> >>
> >> I personally do not, but we may eventually find j.u.concurrent quite
> >> useful in HttpConn.
> >>
> >> I suggest the following course of actions:
> >> (1) I'll run a poll on the minimal JRE requirement on the user list
> >> (2) if JRE 1.5 gets a simple majority of user votes, I'll call for a
> >> formal vote on the dev list.
> >
> > So if there are 201 replies, of whom 100 say they cannot upgrade to
> > 1.5, the decision is to require 1.5?
> >
>
> I would say yes, as it will take at least a year before HttpClient 4.0
> goes final.
It would probably be useful to say this when calling for a vote.
> > I think the vote needs to be significantly more than a simple majority.
> >
>
> Would you be more comfortable with an absolute majority (2/3)?
Yes.
> Oleg
>
> >> (3) simple majority of binding votes will finalize the decision.
> >>
> >> Does this sound all right?
> >>
> >> Oleg
> >>
> >>
> >>> cheers,
> >>> Roland
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> >>> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: requirements, dependencies, jdk...
Posted by Oleg Kalnichevski <ol...@apache.org>.
sebb wrote:
> On 15/11/2007, Oleg Kalnichevski <ol...@apache.org> wrote:
>> Roland Weber wrote:
>>> Hi all,
>>>
>>> I also think that changing the JDK requirement for HttpCore
>>> between the last alpha and first beta would be a case of
>>> very poor timing. Even if 1.3 compatibility becomes obsolete,
>>> there will always be mobile devices where the full J2SE is
>>> not available. We can reconsider the minimum requirements
>>> for HttpCore 4.1.
>>>
>>> For HttpClient, I don't care about the minimum JDK level,
>>> as long as you don't expect me to learn Java 5 over night :-)
>>>
>> Hi Roland
>>
>> I personally do not, but we may eventually find j.u.concurrent quite
>> useful in HttpConn.
>>
>> I suggest the following course of actions:
>> (1) I'll run a poll on the minimal JRE requirement on the user list
>> (2) if JRE 1.5 gets a simple majority of user votes, I'll call for a
>> formal vote on the dev list.
>
> So if there are 201 replies, of whom 100 say they cannot upgrade to
> 1.5, the decision is to require 1.5?
>
I would say yes, as it will take at least a year before HttpClient 4.0
goes final.
> I think the vote needs to be significantly more than a simple majority.
>
Would you be more comfortable with an absolute majority (2/3)?
Oleg
>> (3) simple majority of binding votes will finalize the decision.
>>
>> Does this sound all right?
>>
>> Oleg
>>
>>
>>> cheers,
>>> Roland
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: requirements, dependencies, jdk...
Posted by sebb <se...@gmail.com>.
On 15/11/2007, Oleg Kalnichevski <ol...@apache.org> wrote:
> Roland Weber wrote:
> > Hi all,
> >
> > I also think that changing the JDK requirement for HttpCore
> > between the last alpha and first beta would be a case of
> > very poor timing. Even if 1.3 compatibility becomes obsolete,
> > there will always be mobile devices where the full J2SE is
> > not available. We can reconsider the minimum requirements
> > for HttpCore 4.1.
> >
> > For HttpClient, I don't care about the minimum JDK level,
> > as long as you don't expect me to learn Java 5 over night :-)
> >
>
> Hi Roland
>
> I personally do not, but we may eventually find j.u.concurrent quite
> useful in HttpConn.
>
> I suggest the following course of actions:
> (1) I'll run a poll on the minimal JRE requirement on the user list
> (2) if JRE 1.5 gets a simple majority of user votes, I'll call for a
> formal vote on the dev list.
So if there are 201 replies, of whom 100 say they cannot upgrade to
1.5, the decision is to require 1.5?
I think the vote needs to be significantly more than a simple majority.
> (3) simple majority of binding votes will finalize the decision.
>
> Does this sound all right?
>
> Oleg
>
>
> > cheers,
> > Roland
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: requirements, dependencies, jdk...
Posted by Oleg Kalnichevski <ol...@apache.org>.
Roland Weber wrote:
> Hi all,
>
> I also think that changing the JDK requirement for HttpCore
> between the last alpha and first beta would be a case of
> very poor timing. Even if 1.3 compatibility becomes obsolete,
> there will always be mobile devices where the full J2SE is
> not available. We can reconsider the minimum requirements
> for HttpCore 4.1.
>
> For HttpClient, I don't care about the minimum JDK level,
> as long as you don't expect me to learn Java 5 over night :-)
>
Hi Roland
I personally do not, but we may eventually find j.u.concurrent quite
useful in HttpConn.
I suggest the following course of actions:
(1) I'll run a poll on the minimal JRE requirement on the user list
(2) if JRE 1.5 gets a simple majority of user votes, I'll call for a
formal vote on the dev list.
(3) simple majority of binding votes will finalize the decision.
Does this sound all right?
Oleg
> cheers,
> Roland
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: requirements, dependencies, jdk...
Posted by Roland Weber <os...@dubioso.net>.
Hi Odi,
poor phrasing from my side. I meant to write
"mobile and embedded devices" instead of just "mobile".
> Please note the completely different
> networking APIs of J2SE and MIDP
It's been a while since I looked at the J2ME JavaDocs.
I'd be shooting for CDC first, I believe that is one
of the supported execution environments for OSGi. [1]
When I find the time... meaning probably never :-(
cheers,
Roland
[1]
http://mail-archives.apache.org/mod_mbox/felix-dev/200507.mbox/%3c200507291952.22508.niclas@hedhman.org%3e
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
real/perceived requirements, dependencies, jdk...
Posted by Stojce Dimski <sd...@yahoo.it>.
Questions that I raised are about taking the benefits from some
advancements in platform (language, libraries, tools) at reasonable
cost of some dependencies...
1) Migrating the source to Java5
with use of 'retroweaver' brings just build time dependency for those
who want to rebuild from source, produced artifacts are not dependant
from Java5...
So this is trivial issue for many consumers of this library out there,
but can bring some benefits for those who develop this code base...
2) Use of runtime dependencies
I spoke of just one 'java.util.concurrent' which is very, very, very,
very widely used and would be necessary just for those 1.4 platforms
and is no dependency on Java5, Java6 etc... Common, it is not some
esoteric library it's part of JRE...
The case of 'google-collections' was just a provocation, as those will
by 90% be part of Java7 and will be 'backported' to Java5 and Java6,
something like 'java.util.concurrent' 2 the revenge ;-)
I admit that timing is not perfect but it's better to do something now
than later...
___________________________________
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: requirements, dependencies, jdk...
Posted by Ortwin Glück <od...@odi.ch>.
Roland Weber wrote:
> Hi all,
>
> I also think that changing the JDK requirement for HttpCore
> between the last alpha and first beta would be a case of
> very poor timing. Even if 1.3 compatibility becomes obsolete,
> there will always be mobile devices where the full J2SE is
> not available. We can reconsider the minimum requirements
> for HttpCore 4.1.
>
> For HttpClient, I don't care about the minimum JDK level,
> as long as you don't expect me to learn Java 5 over night :-)
>
> cheers,
> Roland
>
What you most likely want on a mobile device is a simple client to make
individual requests to one server. No need for the server side for now
(until mobile devices all have an IPv6 address). Support for concurrent
requests is purely optional. Of course the MIDP API has a HTTP client
built-in. Although the API is crap (timeout handling) and
implementations are buggy (chunked TE, char encoding, 100 cont, etc.).
But it's built-in and comes at no additional footprint. On J2SE it's a
lot better, but it lacks some advanced features. For me the big question
is: what are the important features for the mobile platform? What's the
reason that you can't use the standard API?
On the other hand, computing resources on mobiles will increase and
platforms will become more PC-like. For me that means MIDP will
eventually be replaced by full J2SE implementations (and .NET). The
Android is just one example.
So, what's important, is not that HttpClient is compatible with mobile
devices. But that you can *build* a specialized HttpClient for mobile
devices upon HttpComponents. Please note the completely different
networking APIs of J2SE and MIDP, and there is virtually no support for
reflection and ClassLoaders, Logging is also a problem. Even JDK 1.3 is
a *lot* bigger than MIDP.
Thus the core libraries *should* be relatively easy to
port/translate/compile to J2ME, while HttpClient's focus can be J2SE
exclusively. But I don't think our primary focus is mobile devices (even
though they are very important) at the moment. And 1.3 compatibility may
somewhat help in porting, but doesn't make it compatible automatically
with MIDP. If someone wants to start a MobileHttpClient, go for it - it
will get a home under the new TLP. Then we can start to work together on
the core libraries, so that they are of the most use for both.
Odi
--
[web] http://www.odi.ch/
[blog] http://www.odi.ch/weblog/
[pgp] key 0x81CF3416
finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: requirements, dependencies, jdk...
Posted by Roland Weber <os...@dubioso.net>.
Hi all,
I also think that changing the JDK requirement for HttpCore
between the last alpha and first beta would be a case of
very poor timing. Even if 1.3 compatibility becomes obsolete,
there will always be mobile devices where the full J2SE is
not available. We can reconsider the minimum requirements
for HttpCore 4.1.
For HttpClient, I don't care about the minimum JDK level,
as long as you don't expect me to learn Java 5 over night :-)
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org