You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gary Gregory <gg...@seagullsw.com> on 2004/01/16 04:22:57 UTC
RE: [codec] More thoughts on CharSets and Encoders (references: R
E: [codec] Streamable Codec Framework)
The only very vague advice/feeling I have on NIO and 1.4 APIs and using 1.4
APIs "eventually" is:
(1) "eventually" is, sadly I think, a ways off in the future. See
discussions on this list WRT J2ee containers, WebSphere, most common
installed base of such containers, etc.
(2) What could be done, and please forgive my lack of intimacy with these
APIs, is to create [codec] APIs that are forward compatible to any extent
possible. What I mean by this if NIO has a class Foo with methods a() and
b(Foo) is to create an equivalent [codec] class Bar with methods a() and
b(Bar), which would allow one to do search and replace in the future. This
is quite a stretch I know, but guess what, we've done this at work in the
logging domain (we have our own logging which we want to eventually move to
1.4 or log4j).
Gary
> -----Original Message-----
> From: Mark R. Diggory [mailto:mdiggory@latte.harvard.edu]
> Sent: Thursday, January 15, 2004 09:38
> To: Jakarta Commons Developers List
> Subject: [codec] More thoughts on CharSets and Encoders (references: RE:
> [codec] Streamable Codec Framework)
>
> I've been heavily reviewing the NIO api in 1.4 to understand more fully
> its capabilities. j2sdk nio provides Charsets (ServiceProviders,
> Encoders, Decoders)
>
> http://java.sun.com/j2se/1.4.2/docs/api/java/nio/charset/package-
> summary.html
> http://java.sun.com/j2se/1.4.2/docs/api/java/nio/charset/spi/CharsetProvid
> er.html
>
> Observations:
>
> NIO already sports API's for Charactersets and encoding. It would appear
> to also be a strong point of "convergence" for Character Encoding given
> that its already in the j2sdk.
>
> Does CharSet/Util's in [lang] approach a similar functionality to
> nio.charset? After reviewing the codebase, my viewpoint is no, as it is
> more for "building" charsets, than for using them (authors rebuttals
> always welcome).
>
> I think [httpclients] static ASCII methods (once in HttpConstants) now
> also in [codec-multipart] are very similar in functionality to the idea
> of CharsetEncoders/Decoders of nio.charset.
>
> So we begin to have functionality for charset's in [lang] and for
> encoders in [codec]. How do we bring this all together? I'd like to see
> similar CharsetEncoding/Decoding capabilities as nio (with the eventual
> goal of actually having Jakarta Commons converge to using nio of
> Charsets in the future.
>
> As a possible bridge for transition I think a CharsetEncoder API in
> [codec] that duplicates that of nio.charset would form an excellent path
> for convergence. The eventual goal once j2sdk1.3 was no longer in
> service would be to simply refactor Apache Projects dependent on this
> API to use NIO instead.
>
> Which does bring us back to the StreamableCodec Discussion where
> "java.nio.charset" was recently discussed:
>
> http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg29450.html
> http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg29951.html
>
> In that thread: Brett stated:
>
> > What support is there within the JDK for performing
> > character to byte conversion?
> > JDK1.4 has the java.nio.charset package but I can't
> > see an equivalent for JDK1.3 and lower, they seem to
> > use com.sun classes internally when charset conversion
> > is required.
> >
> > If JDK1.4 is considered a sufficient base, I could
> > extend the current framework to provide conversion
> > engines that translate from one data representation
> > to another. I could then create a new CodecEngine
> > interface to handle character buffers (eg.
> > CodecEngineChar).
>
> Gary responded:
>
> >> If JDK1.4 is considered a sufficient base, I could
> >
> > I think tha considering 1.3.1 as the base requirement is safe.
> > Unfortunately, as discussed on this list under various heading, making
> 1.4 a
> > requirement is too aggressive.
> >
> > Gary
>
> Yes, we're still supporting 1.3 in many cases, BUT, wouldn't we want
> convergence eventually to the API's provided by the j2sdk? AND, by that
> point in the future, is j2sdk 1.3 even going to be in play?
>
> -Mark
> --
> Mark Diggory
> Software Developer
> Harvard MIT Data Center
> http://osprey.hmdc.harvard.edu
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [codec] More thoughts on CharSets and Encoders (references: R E: [codec] Streamable Codec Framework)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Quoting Oleg Kalnichevski <ol...@bluewin.ch>:
> > The most important phrase in Craig's email was: "As such, I'm
> > personally not interested in working on any revolutionary Struts or
> > Commons designs that do not presume at least J2SE 1.4 / J2EE 1.4 as the
> > base platform as the minimum requirement."
>
> Tim & Craig,
>
> I wish I could agree with you,
Not really asking you to, since it was an expression of where *I* am going to
focus my own personal efforts :-).
> but unfortunately I have to say that this
> is a very PC- (or let me say big-time computing) centric point of view.
> There are still enough platforms that are in a widespread use where even
> Java 1.2 is not available, for instance MacOS 9 and, more importantly,
> all sorts of micro devices and embedded systems. True, it does not make
> sense to run Struts on a PDA or on a mobile phone. However,
> commons-codec being a low level library may come quite handy when
> developing applications for PDAs. Same story goes for HttpClient, which
> has recently become dependent on commons-codec. HttpClient in its turn
> is a dependency for XML-RPM. Making Codec require Java 1.4 (at this
> point) will cause a rippling effect on many other projects which are
> dependent (either directly or indirectly) on this library.
>
> IMHO, Commons-Codec as well as Commons HttpClient being low level
> libraries should target as wider user base as possible. Funny enough, we
> (HttpClient) still get requests for Java 1.1.8 compatibility once in a
> while. Some people went ever as far as creating a semi-official Java
> 1.1.8 fork to cater to their specific needs. The last thing I would like
> to see is a Java 1.2.x fork in addition to that.
>
> I am not saying Codec should not go forward and adopt new features in
> the Java platform that sense for it. However, we should consider not
> only the risk of working ourselves out of existence but also the risk of
> ending up working just for ourselves.
>
> At the very least I would like to see a more coherent policy towards
> Java platform compatibility across all Commons sub-project. I believe
> there must be a common baseline we should all agree upon and then stick
> to, whatever it is.
>
It's up to the developers of each package. The best way to influence that
decision, for the packages that people care about, is to become a developer on
them :-).
Most appear to have settled on 1.2 as a base platform, with some still trying to
make provisions for 1.1. But this decision has negative consquences for
Jakarta packages as well -- it means we tend to spend a lot of time
re-inventing what is already available, and we tend to not even think about
designs that are enabled by the newer JDK's features, simply because it would
take lots of work to write corresponding support for pre-1.4 users. Over the
last couple of years, the net result of this (across all the Jakarta projects
I'm familiar with) is a gradual reduction in innovation and new ideas.
I'm not a codec contributor, so I don't have a voice in the decision for that
package. I agree with your point that the use cases are likely to be
different. Also, one could jusifiably accuse me of hijacking this message
thread :-)
But I really would like to see Jakarta projects do things for all the 1.4 users
in the world, even if it means that code won't be helping users on pre-1.4
systems. And, since my primary interest is on server side apps (where 1.4 is
more commonly available, or will be very soon), that's where I'm going to
focus.
> Cheers,
>
> Oleg
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [codec] More thoughts on CharSets and Encoders (references: R
E: [codec] Streamable Codec Framework)
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Oleg Kalnichevski wrote:
>>The most important phrase in Craig's email was: "As such, I'm
>>personally not interested in working on any revolutionary Struts or
>>Commons designs that do not presume at least J2SE 1.4 / J2EE 1.4 as the
>>base platform as the minimum requirement."
>
>
> Tim & Craig,
>
> I wish I could agree with you, but unfortunately I have to say that this
> is a very PC- (or let me say big-time computing) centric point of view.
> There are still enough platforms that are in a widespread use where even
> Java 1.2 is not available, for instance MacOS 9 and, more importantly,
> all sorts of micro devices and embedded systems. True, it does not make
> sense to run Struts on a PDA or on a mobile phone. However,
> commons-codec being a low level library may come quite handy when
> developing applications for PDAs. Same story goes for HttpClient, which
> has recently become dependent on commons-codec. HttpClient in its turn
> is a dependency for XML-RPM. Making Codec require Java 1.4 (at this
> point) will cause a rippling effect on many other projects which are
> dependent (either directly or indirectly) on this library.
>
> IMHO, Commons-Codec as well as Commons HttpClient being low level
> libraries should target as wider user base as possible. Funny enough, we
> (HttpClient) still get requests for Java 1.1.8 compatibility once in a
> while. Some people went ever as far as creating a semi-official Java
> 1.1.8 fork to cater to their specific needs. The last thing I would like
> to see is a Java 1.2.x fork in addition to that.
>
> I am not saying Codec should not go forward and adopt new features in
> the Java platform that sense for it. However, we should consider not
> only the risk of working ourselves out of existence but also the risk of
> ending up working just for ourselves.
>
> At the very least I would like to see a more coherent policy towards
> Java platform compatibility across all Commons sub-project. I believe
> there must be a common baseline we should all agree upon and then stick
> to, whatever it is.
>
> Cheers,
>
> Oleg
I still really get a strong sense that more "Tag and Branching" would be
an empowerment here, HttpClient for j2sdk 1.4 and greater could take
advantage of those features 1.4 provides (for instance "nio") while a
maintence branch on < 1.4 could maintain release for those specific JVM's.
-Mark
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [codec] More thoughts on CharSets and Encoders (references: R
E: [codec] Streamable Codec Framework)
Posted by Oleg Kalnichevski <ol...@bluewin.ch>.
> The most important phrase in Craig's email was: "As such, I'm
> personally not interested in working on any revolutionary Struts or
> Commons designs that do not presume at least J2SE 1.4 / J2EE 1.4 as the
> base platform as the minimum requirement."
Tim & Craig,
I wish I could agree with you, but unfortunately I have to say that this
is a very PC- (or let me say big-time computing) centric point of view.
There are still enough platforms that are in a widespread use where even
Java 1.2 is not available, for instance MacOS 9 and, more importantly,
all sorts of micro devices and embedded systems. True, it does not make
sense to run Struts on a PDA or on a mobile phone. However,
commons-codec being a low level library may come quite handy when
developing applications for PDAs. Same story goes for HttpClient, which
has recently become dependent on commons-codec. HttpClient in its turn
is a dependency for XML-RPM. Making Codec require Java 1.4 (at this
point) will cause a rippling effect on many other projects which are
dependent (either directly or indirectly) on this library.
IMHO, Commons-Codec as well as Commons HttpClient being low level
libraries should target as wider user base as possible. Funny enough, we
(HttpClient) still get requests for Java 1.1.8 compatibility once in a
while. Some people went ever as far as creating a semi-official Java
1.1.8 fork to cater to their specific needs. The last thing I would like
to see is a Java 1.2.x fork in addition to that.
I am not saying Codec should not go forward and adopt new features in
the Java platform that sense for it. However, we should consider not
only the risk of working ourselves out of existence but also the risk of
ending up working just for ourselves.
At the very least I would like to see a more coherent policy towards
Java platform compatibility across all Commons sub-project. I believe
there must be a common baseline we should all agree upon and then stick
to, whatever it is.
Cheers,
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [codec] More thoughts on CharSets and Encoders (references: R
E: [codec] Streamable Codec Framework)
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
What about the idea of employing more "Tag and Branch" Approaches in
Commons that parellel JVM, Servlet/JSP, Tomcat or (basically any parent
platform/dependency space)?
This way developers with an interest in maintain backward compatability
and support bugfixing to these "spaces" can continue to do so while the
Head stays more adventurous...
-Mark
Tim O'Brien wrote:
> A +1 for Craig's comments.
>
> If there are users who still have 1.2 requirements going forward, I say
> should say to them, you need to take it upon yourself to make the case
> for an upgrade, or work actively in this community to write components
> that work with 1.2.
>
> The most important phrase in Craig's email was: "As such, I'm
> personally not interested in working on any revolutionary Struts or
> Commons designs that do not presume at least J2SE 1.4 / J2EE 1.4 as the
> base platform as the minimum requirement." I am of the same persuasion,
> and if we create a community in which developers do not want to
> participate, we're working ourselves out of existence. And, I believe
> that is what we are seeing right now.
>
> Tim
>
>
>
> Craig R. McClanahan wrote:
>
>> Quoting Gary Gregory <gg...@seagullsw.com>:
>>
>>
>>
>>> (1) "eventually" is, sadly I think, a ways off in the future. See
>>> discussions on this list WRT J2ee containers, WebSphere, most common
>>> installed base of such containers, etc.
>>>
>>>
>>
>>
>> <personal-viewpoint author="craigmcc">
>>
>> As a major proponent of long-term support for existing packages that
>> want to do
>> evolutionary development, this is an important issue. My own
>> experience with
>> Struts (which still supports Servlet 2.2 / JSP 1.1) says that this is
>> important
>> for existing users. And it will continue to be. *Nobody* in the real
>> world
>> can migrate to more current technologies as fast as the developers of
>> those
>> technologies would wish that they could.
>>
>> However, I get really impatient with this reality for *future* users.
>> Many/most
>> Jakarta projects tend to focus on the "what is widely deployed now"
>> scenario --
>> but limiting ongoing development to this kind of platform is *very*
>> bad for the
>> Java platform in the long run.
>>
>> Personally, I will continue to invest effort in supporting existing
>> users of
>> the
>> Apache/Jakarta packages I contribute to. But my primary focus for future
>> efforts are going to be focused on leveraging the platforms that are more
>> current in the mainstream ... with the expectation that folks on
>> platforms that
>> don't have this current support *will* be taken care of by the time
>> that the
>> revolutionary software is (if it ever is) ready for general release.
>>
>> As such, I'm personally not interested in working on any revolutionary
>> Struts
>> or
>> Commons designs that do not presume at least J2SE 1.4 / J2EE 1.4 as
>> the base
>> platform as the minimum requirement. That's not to say that the needs of
>> exisiting pre-1.4-based users, or non-mainstream platforms that don't
>> support
>> SE/EE 1.4, aren't important --- nothing could be further from the
>> truth! -- but
>> limiting the ongoing development of Jakarta-based software (overall, the
>> convention seems to be to support JDK 1.2 as the minimum platform with
>> some
>> packages supporting 1.1 compatible versions) is going to be very
>> detrimental to
>> the long-term success of the Java platform.
>>
>> The JDK 1.2 environment was *years* ago ... when a 256mHz PC was the
>> tip of the
>> state of the art. Would you willing to accept being required to work
>> on such a
>> hardware system today?
>>
>> It's time for us to recognize that there are *millions* of mainstream
>> users,
>> who
>> *can* provide a 1.4 baseline runtime environmment -- and, as a whole, the
>> Jakarta community is not paying enough attention to what kinds of
>> capabilities
>> can not be assumed. Lets *stop* limiting our revolutionary advances
>> by an
>> assumption that we have to be backwards compatible with what (in computer
>> terms) is now considered the Iron Age of computing.
>> </personal-viewpoint>
>>
>> Craig McClanahan
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [codec] More thoughts on CharSets and Encoders (references: R
E: [codec] Streamable Codec Framework)
Posted by Tim O'Brien <to...@discursive.com>.
A +1 for Craig's comments.
If there are users who still have 1.2 requirements going forward, I say
should say to them, you need to take it upon yourself to make the case
for an upgrade, or work actively in this community to write components
that work with 1.2.
The most important phrase in Craig's email was: "As such, I'm
personally not interested in working on any revolutionary Struts or
Commons designs that do not presume at least J2SE 1.4 / J2EE 1.4 as the
base platform as the minimum requirement." I am of the same persuasion,
and if we create a community in which developers do not want to
participate, we're working ourselves out of existence. And, I believe
that is what we are seeing right now.
Tim
Craig R. McClanahan wrote:
>Quoting Gary Gregory <gg...@seagullsw.com>:
>
>
>
>>(1) "eventually" is, sadly I think, a ways off in the future. See
>>discussions on this list WRT J2ee containers, WebSphere, most common
>>installed base of such containers, etc.
>>
>>
>>
>
><personal-viewpoint author="craigmcc">
>
>As a major proponent of long-term support for existing packages that want to do
>evolutionary development, this is an important issue. My own experience with
>Struts (which still supports Servlet 2.2 / JSP 1.1) says that this is important
>for existing users. And it will continue to be. *Nobody* in the real world
>can migrate to more current technologies as fast as the developers of those
>technologies would wish that they could.
>
>However, I get really impatient with this reality for *future* users.
>Many/most
>Jakarta projects tend to focus on the "what is widely deployed now" scenario --
>but limiting ongoing development to this kind of platform is *very* bad for the
>Java platform in the long run.
>
>Personally, I will continue to invest effort in supporting existing users of
>the
>Apache/Jakarta packages I contribute to. But my primary focus for future
>efforts are going to be focused on leveraging the platforms that are more
>current in the mainstream ... with the expectation that folks on platforms that
>don't have this current support *will* be taken care of by the time that the
>revolutionary software is (if it ever is) ready for general release.
>
>As such, I'm personally not interested in working on any revolutionary Struts
>or
>Commons designs that do not presume at least J2SE 1.4 / J2EE 1.4 as the base
>platform as the minimum requirement. That's not to say that the needs of
>exisiting pre-1.4-based users, or non-mainstream platforms that don't support
>SE/EE 1.4, aren't important --- nothing could be further from the truth! -- but
>limiting the ongoing development of Jakarta-based software (overall, the
>convention seems to be to support JDK 1.2 as the minimum platform with some
>packages supporting 1.1 compatible versions) is going to be very detrimental to
>the long-term success of the Java platform.
>
>The JDK 1.2 environment was *years* ago ... when a 256mHz PC was the tip of the
>state of the art. Would you willing to accept being required to work on such a
>hardware system today?
>
>It's time for us to recognize that there are *millions* of mainstream users,
>who
>*can* provide a 1.4 baseline runtime environmment -- and, as a whole, the
>Jakarta community is not paying enough attention to what kinds of capabilities
>can not be assumed. Lets *stop* limiting our revolutionary advances by an
>assumption that we have to be backwards compatible with what (in computer
>terms) is now considered the Iron Age of computing.
></personal-viewpoint>
>
>Craig McClanahan
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [codec] More thoughts on CharSets and Encoders (references: R E: [codec] Streamable Codec Framework)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Quoting Gary Gregory <gg...@seagullsw.com>:
> (1) "eventually" is, sadly I think, a ways off in the future. See
> discussions on this list WRT J2ee containers, WebSphere, most common
> installed base of such containers, etc.
>
<personal-viewpoint author="craigmcc">
As a major proponent of long-term support for existing packages that want to do
evolutionary development, this is an important issue. My own experience with
Struts (which still supports Servlet 2.2 / JSP 1.1) says that this is important
for existing users. And it will continue to be. *Nobody* in the real world
can migrate to more current technologies as fast as the developers of those
technologies would wish that they could.
However, I get really impatient with this reality for *future* users.
Many/most
Jakarta projects tend to focus on the "what is widely deployed now" scenario --
but limiting ongoing development to this kind of platform is *very* bad for the
Java platform in the long run.
Personally, I will continue to invest effort in supporting existing users of
the
Apache/Jakarta packages I contribute to. But my primary focus for future
efforts are going to be focused on leveraging the platforms that are more
current in the mainstream ... with the expectation that folks on platforms that
don't have this current support *will* be taken care of by the time that the
revolutionary software is (if it ever is) ready for general release.
As such, I'm personally not interested in working on any revolutionary Struts
or
Commons designs that do not presume at least J2SE 1.4 / J2EE 1.4 as the base
platform as the minimum requirement. That's not to say that the needs of
exisiting pre-1.4-based users, or non-mainstream platforms that don't support
SE/EE 1.4, aren't important --- nothing could be further from the truth! -- but
limiting the ongoing development of Jakarta-based software (overall, the
convention seems to be to support JDK 1.2 as the minimum platform with some
packages supporting 1.1 compatible versions) is going to be very detrimental to
the long-term success of the Java platform.
The JDK 1.2 environment was *years* ago ... when a 256mHz PC was the tip of the
state of the art. Would you willing to accept being required to work on such a
hardware system today?
It's time for us to recognize that there are *millions* of mainstream users,
who
*can* provide a 1.4 baseline runtime environmment -- and, as a whole, the
Jakarta community is not paying enough attention to what kinds of capabilities
can not be assumed. Lets *stop* limiting our revolutionary advances by an
assumption that we have to be backwards compatible with what (in computer
terms) is now considered the Iron Age of computing.
</personal-viewpoint>
Craig McClanahan
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: [codec] More thoughts on CharSets and Encoders (references: R E: [codec] Streamable Codec Framework)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Quoting Gary Gregory <gg...@seagullsw.com>:
> (1) "eventually" is, sadly I think, a ways off in the future. See
> discussions on this list WRT J2ee containers, WebSphere, most common
> installed base of such containers, etc.
>
<personal-viewpoint author="craigmcc">
As a major proponent of long-term support for existing packages that want to do
evolutionary development, this is an important issue. My own experience with
Struts (which still supports Servlet 2.2 / JSP 1.1) says that this is important
for existing users. And it will continue to be. *Nobody* in the real world
can migrate to more current technologies as fast as the developers of those
technologies would wish that they could.
However, I get really impatient with this reality for *future* users.
Many/most
Jakarta projects tend to focus on the "what is widely deployed now" scenario --
but limiting ongoing development to this kind of platform is *very* bad for the
Java platform in the long run.
Personally, I will continue to invest effort in supporting existing users of
the
Apache/Jakarta packages I contribute to. But my primary focus for future
efforts are going to be focused on leveraging the platforms that are more
current in the mainstream ... with the expectation that folks on platforms that
don't have this current support *will* be taken care of by the time that the
revolutionary software is (if it ever is) ready for general release.
As such, I'm personally not interested in working on any revolutionary Struts
or
Commons designs that do not presume at least J2SE 1.4 / J2EE 1.4 as the base
platform as the minimum requirement. That's not to say that the needs of
exisiting pre-1.4-based users, or non-mainstream platforms that don't support
SE/EE 1.4, aren't important --- nothing could be further from the truth! -- but
limiting the ongoing development of Jakarta-based software (overall, the
convention seems to be to support JDK 1.2 as the minimum platform with some
packages supporting 1.1 compatible versions) is going to be very detrimental to
the long-term success of the Java platform.
The JDK 1.2 environment was *years* ago ... when a 256mHz PC was the tip of the
state of the art. Would you willing to accept being required to work on such a
hardware system today?
It's time for us to recognize that there are *millions* of mainstream users,
who
*can* provide a 1.4 baseline runtime environmment -- and, as a whole, the
Jakarta community is not paying enough attention to what kinds of capabilities
can not be assumed. Lets *stop* limiting our revolutionary advances by an
assumption that we have to be backwards compatible with what (in computer
terms) is now considered the Iron Age of computing.
</personal-viewpoint>
Craig McClanahan
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [codec] More thoughts on CharSets and Encoders (references: R
E: [codec] Streamable Codec Framework)
Posted by __matthewHawthorne <ma...@phreaker.net>.
Gary Gregory wrote:
> (2) What could be done, and please forgive my lack of intimacy with these
> APIs, is to create [codec] APIs that are forward compatible to any extent
> possible. What I mean by this if NIO has a class Foo with methods a() and
> b(Foo) is to create an equivalent [codec] class Bar with methods a() and
> b(Bar), which would allow one to do search and replace in the future. This
> is quite a stretch I know, but guess what, we've done this at work in the
> logging domain (we have our own logging which we want to eventually move to
> 1.4 or log4j).
An alternative to the search-and-replace could be to create an interface
which defines the requirements of the functionality that you need. You
could then provide a default implementation of the interface, use the
Factory pattern to obtain instances, and then in the future, plug in an
implementation which delegates to the corresponding 1.4 class once it
becomes available in jakarta-land.
This could make things transparent to the outside. I've been able to
pull this off a few times when I was in the 1.3 to 1.4 transition (I had
my own logger too), and I've also been able to plug trash my home-grown
solutions in favor of swift libraries such as [dbcp] and [betwixt].
Maybe this is what you were saying and I misunderstood you. Either way,
it's painful to not be able to use 1.4, especially with 1.5's new tricks
on the horizon. ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org