Re: JAVA_HOME

Discussion in 'Java' started by angrybaldguy@gmail.com, Dec 24, 2008.

  1. Guest

    On Dec 24, 10:34 am, wrote:
    > I've just installed tomcat using aptitude on my Debian system.
    > I think I've got $CATALINA_HOME pointing at the right place.
    > How can I tell where to point $JAVA_HOME to?


    Installing tomcat via the package manager also installs a number of
    tools, including init scripts. You don't need to manipulate
    CATALINA_HOME or JAVA_HOME yourself: sudo /etc/init.d/tomcat* start
    will start up Tomcat using the current system JDK and the correct
    Catalina environment.

    > www:~# java -version
    > java version "1.4.2"
    > gij (GNU libgcj) version 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)
    >
    > Copyright (C) 2006 Free Software Foundation, Inc.
    > This is free software; see the source for copying conditions.  There
    > is NO
    > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
    > PURPOSE.
    >
    > so I think java is installed ok.


    GNU GCJ (which includes GIJ) is, for all intents and purposes, *NOT
    JAVA*. It has a number of shortcomings with respect to the JRE.
    Install one of the Sun java packages:

    sudo apt-get install sun-java6-jdk
    sudo update-java-alternatives --set java-6-sun

    For more information you probably want to talk to a Debian group; this
    is really about configuring your OS, not about Java itself.

    -o
     
    , Dec 24, 2008
    #1
    1. Advertising

  2. Lew Guest

    On Dec 24, 10:42 am, wrote:
    > On Dec 24, 10:34 am, wrote:
    >
    > > I've just installed tomcat using aptitude on my Debian system.
    > > I think I've got $CATALINA_HOME pointing at the right place.
    > > How can I tell where to point $JAVA_HOME to?

    >
    > Installing tomcat via the package manager also installs a number of
    > tools, including init scripts. You don't need to manipulate
    > CATALINA_HOME or JAVA_HOME yourself: sudo /etc/init.d/tomcat* start
    > will start up Tomcat using  the current system JDK and the correct
    > Catalina environment.
    >
    > > www:~# java -version
    > > java version "1.4.2"
    > > gij (GNU libgcj) version 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)

    >
    > > Copyright (C) 2006 Free Software Foundation, Inc.
    > > This is free software; see the source for copying conditions.  There
    > > is NO
    > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
    > > PURPOSE.

    >
    > > so I think java is installed ok.


    It is not.

    > GNU GCJ (which includes GIJ) is, for all intents and purposes, *NOT
    > JAVA*. It has a number of shortcomings with respect to the JRE.


    Among which is that Java 1.4 is an unsupported, obsolete version of
    Java.

    > Install one of the Sun java packages:
    >
    >   sudo apt-get install sun-java6-jdk
    >   sudo update-java-alternatives --set java-6-sun
    >
    > For more information you probably want to talk to a Debian group; this
    > is really about configuring your OS, not about Java itself.


    JAVA_HOME should contain the root directory of your JDK installation.

    For example, if you have Java installed to /opt/java/jdk1.6.0_11, then
    you set JAVA_HOME to "/opt/java/jdk1.6.0_11".

    --
    Lew
     
    Lew, Dec 24, 2008
    #2
    1. Advertising

  3. Arne Vajhøj Guest

    Lew wrote:
    > On Dec 24, 10:42 am, wrote:
    >> GNU GCJ (which includes GIJ) is, for all intents and purposes, *NOT
    >> JAVA*. It has a number of shortcomings with respect to the JRE.

    >
    > Among which is that Java 1.4 is an unsupported, obsolete version of
    > Java.


    1.4 is most definitely obsolete.

    But can a specification become unsupported ?

    SUN's implementation of 1.4 is unsupported now (unless you
    pay for it).

    Arne
     
    Arne Vajhøj, Dec 30, 2008
    #3
  4. Lew Guest

    wrote:
    >>> GNU GCJ (which includes GIJ) is, for all intents and purposes, *NOT
    >>> JAVA*. It has a number of shortcomings with respect to the JRE.


    Lew wrote:
    >> Among which is that Java 1.4 is an unsupported, obsolete version of
    >> Java.


    Arne Vajhøj wrote:
    > 1.4 is most definitely obsolete.
    >
    > But can a specification become unsupported ?
    >
    > SUN's implementation of 1.4 is unsupported now (unless you
    > pay for it).


    Good question. For that matter, can a specification be supported? But I was
    referring to the implementation.

    When one looks at the Sun site, one sees that version 1.4 has "reached the end
    of its service life (EOSL)", i.e., it's unsupported.
    <http://java.sun.com/j2se/1.4.2/download.html>

    When one looks at the Wikipedia entry for "Java version history", one sees
    that it lists 1.4 as unsupported.
    <http://en.wikipedia.org/wiki/Java_version_history>

    How do you interpret their statements?

    Fat lot of good the specification does you if the implementation is
    unsupported. Besides, there were significant improvements between Java 1.4
    and 5, notably in the memory model and the APIs. That means there is risk in
    staying with the obsolete implementations of the obsolete specification.

    How much support can one get for GCJ and its obsolete implementation of Java?

    Java 1.4 is almost seven years old. Java 5 is four years old, and in
    end-of-life its own self. Java 6 is two years old already. The downloads are
    free. The conversion effort is not egregious - I was on a project that
    converted approximately a half million lines of code from Java 1.3 to Java 5
    in about a month with two people doing the conversion amidst other duties.
    (That's without adding generics and all, just eliminating incompatibilities.)
    Most all of that effort wasn't even in the Java source, but in converting
    Eclipse project files to a newer version and getting the right JARs into the
    classpaths.

    All this fear to upgrade to the current (or nearly current) version of Java is
    misplaced.

    --
    Lew
     
    Lew, Dec 30, 2008
    #4
  5. Lew wrote:
    > wrote:
    >>>> GNU GCJ (which includes GIJ) is, for all intents and purposes, *NOT
    >>>> JAVA*. It has a number of shortcomings with respect to the JRE.

    >
    > Lew wrote:
    >>> Among which is that Java 1.4 is an unsupported, obsolete version of
    >>> Java.

    >
    > Arne Vajhøj wrote:
    >> 1.4 is most definitely obsolete.
    >>
    >> But can a specification become unsupported ?
    >>
    >> SUN's implementation of 1.4 is unsupported now (unless you
    >> pay for it).

    >
    > Good question. For that matter, can a specification be supported? But
    > I was referring to the implementation.


    The implementation discussed in the thread is GCJ not SUN Java.

    > When one looks at the Sun site, one sees that version 1.4 has "reached
    > the end of its service life (EOSL)", i.e., it's unsupported.
    > <http://java.sun.com/j2se/1.4.2/download.html>
    >
    > When one looks at the Wikipedia entry for "Java version history", one
    > sees that it lists 1.4 as unsupported.
    > <http://en.wikipedia.org/wiki/Java_version_history>
    >
    > How do you interpret their statements?


    SUN Java 1.4.2 is unsupported (unless you pay).

    As I wrote.

    > Fat lot of good the specification does you if the implementation is
    > unsupported.


    Not "the implementation" but "most implementations".

    > How much support can one get for GCJ and its obsolete implementation of
    > Java?


    GCJ is actively maintained, so I guess you can get "support".

    > Java 1.4 is almost seven years old. Java 5 is four years old, and in
    > end-of-life its own self. Java 6 is two years old already.


    I don't disagree with your dislike for GCJ.

    I just wanted to emphasize the distinction between the Java
    specification and SUN's implementation.

    The specification becomes obsolete when newer versions come out. The
    implementation becomes unsupported when the responsible company or
    open source project declares that they will no longer provide support.

    > The
    > downloads are free. The conversion effort is not egregious - I was on a
    > project that converted approximately a half million lines of code from
    > Java 1.3 to Java 5 in about a month with two people doing the conversion
    > amidst other duties. (That's without adding generics and all, just
    > eliminating incompatibilities.) Most all of that effort wasn't even in
    > the Java source, but in converting Eclipse project files to a newer
    > version and getting the right JARs into the classpaths.
    >
    > All this fear to upgrade to the current (or nearly current) version of
    > Java is misplaced.


    It is usually not the cost of the code changes but the cost of the test
    that hold conversions back.

    Arne
     
    Arne Vajhøj, Dec 30, 2008
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jason
    Replies:
    3
    Views:
    44,338
    samspade
    Aug 20, 2003
  2. Bob Frank
    Replies:
    0
    Views:
    446
    Bob Frank
    Aug 20, 2004
  3. Paul Moloney
    Replies:
    1
    Views:
    7,207
    Arnaud Berger
    Apr 4, 2005
  4. Mohsen
    Replies:
    1
    Views:
    1,823
    Roedy Green
    Dec 9, 2005
  5. Miss Michelle. Heigardt
    Replies:
    8
    Views:
    143,233
    abbinv
    Apr 9, 2011
Loading...

Share This Page