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]>
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
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.