Re: Barracuda still doesn't compile on JDK 1.3.1

Carlos Santiago <[email protected]>
Newsgroups gmane.comp.java.enhydra.barracuda.general
Message-ID <[email protected]>
Hello Christian,

I agree with the approach of requiring the "latest and greatest"
accross the board. But, keep in mind that many people do not
have control whatsoever as to the base J2EE platform deployed
across one's enterprise, or the speed of getting into the latest
upgrades. In my case that is WLS 6.1 and soon WLS 7.0 w/JDK
1.3.1. The larger the company, it seems the more truth there is to
this practice - a practice which makes some business sense too,
btw (i.e. stability + additional business logic in apps. vs. constant
technical upgrades).

Which reminds me to ask, are there plans to produce JAR versions
of the latest sources of Barracuda? If not, what is the plan to
produce "official" releases of Barracuda?

With the argument described in my first paragraph in mind, it is
more convenient for a project to present a version of library X
to management, than just saying "we are using a CVS drop of
month/day/year".

Good examples of the usefulness of frequent binary distros. are
the Apache/Jakarta projects, which give the projects a sort
of milestone measure, and helps me identify library versions up
the food chain.

Anyway, just keep these things in mind. Again, I agree with the
philosophy of jumping into the latest ASAP, but in the corporate
world it does not seem common for this philosophy to be shared
by upper management, which migth result in minimizing the
number of users that could use Barracuda.

- Carlos

Christian Cryder wrote:

>  Hi Jake,Maybe you are correct here...for some reason I was thinking
> that the servlet apis were included with the JDK, but now that I think
> about it that's probably not correct. So you are right - there
> shouldn't be a hard tie between the servlet API and the JDK (or at
> least not between 1.3 and 1.4).I agree that I would like to get to
> officially requiring the 2.3 version of the servlet spec, but I also
> know that appservers tend to lag a bit. So the question would be - how
> many people would be impacted if we started using 2.3 features? In
> other words, are there any folks out there who _couldn't_ get their
> appservers to work with 2.3, and if so, when do they think they'll be
> able to?Christian----------------------------------------------
> Christian Cryder [[email protected]]
> Internet Architect, ATMReports.com
> Barracuda - http://barracudamvc.org
> ----------------------------------------------
> "Coffee? I could quit anytime, just not today"
>
>      -----Original Message-----
>      From: [email protected]
>      [mailto:[email protected]]On Behalf Of Jacob
>      Kjome
>      Sent: Tuesday, January 21, 2003 8:44 AM
>      To: [email protected]
>      Subject: RE: [Barracuda] Barracuda still doesn't compile on
>      JDK 1.3.1
>
>      Hi Christian,
>
>      Can you point out where servlet-2.3 requires j2sdk1.4.x?  I
>      don't believe this statement is true at all.  It may become
>      true in later specs (servlet-2.4 maybe?).  However, I'm
>      pretty sure that servlet-2.3 has full compatibility with
>      JDK1.3.x.  I don't think Tomcat requires j2sdk1.4.x so that
>      would be evidence that there is no such requirement.   So,
>      the servlet-2.3 compatibility issue is, IMO, a completely
>      different one than the JDK issue.
>
>      That said, I think we may want to start requiring
>      servlet-2.3.  Tomcat-5.0 is well under development which
>      will support the 2.4 spec.  I think it is time to take
>      advantage of the new stuff out there.  Servlet-2.3 has too
>      many advantages over 2.2 to avoid using it.
>
>      Jake
>
>      At 08:30 AM 1/21/2003 -0700, you wrote:
>
>     > This will increasingly become an issue as we want to take
>     > advantage of Servlet 2.3 functionality (I believe JDK 1.3
>     > only supports Servlet 1.2).
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.