RE: Barracuda still doesn't compile on JDK 1.3.1

"Christian Cryder" <[email protected]>
Newsgroups gmane.comp.java.enhydra.barracuda.general
Message-ID <[email protected]>
So what version of the Servlets API is WebLogic using?
----------------------------------------------
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 Udovenko Sergey
  Sent: Tuesday, January 21, 2003 8:59 AM
  To: [email protected]
  Subject: RE: [Barracuda] Barracuda still doesn't compile on JDK 1.3.1


  Weblogic is a problem. We are using WL 6.1 (jdk1.3), but even WL7.0 is
still jdk1.3  :(
  It seems like we will stick with jdk1.3 for quite a while here (years?)...

  Sergey

    -----Original Message-----
    From: Christian Cryder [mailto:[email protected]]
    Sent: Tuesday, January 21, 2003 4:30 PM
    To: [email protected]
    Subject: RE: [Barracuda] Barracuda still doesn't compile on JDK 1.3.1


    Ok, I want to hear from Shawn if the code here can easily be modified to
support both 1.3 and 1.4; my guess is that it probably can.

    This raises a bigger issue however - what do we do in cases where its
not possible to support both, or where we want to take advantage of
something that's available in a higher version but is not in earlier ones.
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).

    I know that there are folks who have complained about Java's lack of
if-defs (like in C), but I'm not totally sure what we can do about it...does
anyone have any suggestions or strategies here?

    The easiest solution is to get everyone onto JDK 1.4 as soon as
possible, but I realize that may be difficult (or impossible). So what
platforms/appservers do not yet have JDK 1.4 support?

    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:12 AM
      To: [email protected]
      Subject: Re: [Barracuda] Barracuda still doesn't compile on JDK 1.3.1


      Hi Franck,

      I agree that Barracuda should be able to be compiled under JDK1.3.x.
Maybe we j2sdk1.5 get released, then we can start basing stuff on
j2sdk1.4.x, but probably not until then unless there is some super
compelling reason to break compatibility with JDK1.3.x before that time.


      Now, not to point fingers, but, Shawn, I think the compile errors
result from stuff you added.  I would try to fix this stuff myself, but you
know more about what you were trying to do here.  I'm not sure about how you
want to handle the getHeaderFields() issue.  I can see why you used
initCause() in the case of ParseException().  initCause() would not be
required if they created the ParseException class with constructors such as
ParseException(String aString, Throwable cause).  That was just bad design
by those developing the Java API which they had to patch with a new method
to the Throwable base class (or you could look at it the other way around
and say that initCause() should have been there all the time avoiding the
annoyance of having so many necessary constructors on any given child class
of Throwable).  Really dumb and inconvenient.  So, what do you propose.
Anyone else have suggestions to do what the code needs to do, but return
compatibility to JDK1.3?

      Jake

      At 11:51 AM 1/21/2003 +0100, you wrote:

        Hi,

        I just downloaded fresh sources from barracudamvc cvs.
        I'm unable to compile on jdk 1.3.1 (be it Sun's or IBM's)

        I get the same error as Stephen Woolerton a few days ago :

        compile_core:
            [javac] Compiling 9 source files to
/home/alci/devel/Barracuda/WEB-INF/classes
            [javac]
/home/alci/devel/Barracuda/src/org/enhydra/barracuda/plankton/http/HttpReque
ster.java:496: cannot resolve symbol
            [javac] symbol  : method getHeaderFields  ()
            [javac] location: class java.net.URLConnection
            [javac]         List scookies = (List)
conn.getHeaderFields().get("Set-Cookie");
            [javac]                                    ^
            [javac]
/home/alci/devel/Barracuda/src/org/enhydra/barracuda/plankton/http/HttpServi
ces.java:88: cannot resolve symbol
            [javac] symbol  : method initCause
(java.lang.NumberFormatException)
            [javac] location: class java.text.ParseException
            [javac]                         ee.initCause(e);
            [javac]                           ^
            [javac]
/home/alci/devel/Barracuda/src/org/enhydra/barracuda/plankton/http/HttpServi
ces.java:97: cannot resolve symbol
            [javac] symbol  : method initCause
(java.lang.NumberFormatException)
            [javac] location: class java.text.ParseException
            [javac]                         ee.initCause(e);
            [javac]                           ^
            [javac]
/home/alci/devel/Barracuda/src/org/enhydra/barracuda/plankton/http/HttpServi
ces.java:105: cannot resolve symbol
            [javac] symbol  : method initCause  (java.text.ParseException)
            [javac] location: class java.text.ParseException
            [javac]                         ee.initCause(e);
            [javac]                           ^
            [javac] 4 errors

        Compiling on jdk 1.4 doesn't show this errors, but this is not an
option for one of my system... (1.4 not yet available)

        Do you think these are 1.4 features we need, or just the fact that
is was not tested on 1.3.1 for quite a time ?

        I'm not skilled enought to tell. For example, the first error is due
to the fact that java.net.URLConnection List getHeaderFiels(String) does not
exist in 1.3.1 API. There is only a public String getHeaderField(String
name). So there might be a need for a modification of the code logic to
iterate to construct a List from strings...

        Error 2, 3 and 4 are due to the fact that java.lang.throwable has
not initCause method in 1.3.1. Event chaining is not handled for this
exception in 1.3.1. (other have their own chaining mecanisms, 1.4 normalized
on this with initCause). Do we really need it (sure it's a plus)

        Well... do we want to keep running on 1.3.1 ? (I must confess I
would like to :-). Can we change the code in plankton to keep compatibility
?

        Up to you, Great Leaders Of Barracuda :-)

        Regards,

        Franck

        _______________________________________________
        Barracuda mailing list
        [email protected]
        http://barracudamvc.org/lists/listinfo/barracuda


  This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission. If
you receive this message in error, please notify the sender urgently and
then immediately delete the message and any copies of it from your system.
Please also immediately destroy any hardcopies of the message. You must not,
directly or indirectly, use, disclose, distribute, print, or copy any part
of this message if you are not the intended recipient. The sender's company
reserves the right to monitor all e-mail communications through their
networks. Any views expressed in this message are those of the individual
sender, except where the message states otherwise and the sender is
authorised to state them to be the views of the sender's company.
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.