Re: Setting up a Java development environment the debian way.

From: Simon Kitching (skitching_at_apache.org)
Date: 06/23/05

  • Next message: Roberto C. Sanchez: "Re: apt-get install won't recover from removal of apache directory in /etc/" 
    To: debian-user@lists.debian.org
Date: Thu, 23 Jun 2005 12:59:51 +1200

    On Wed, 2005-06-22 at 18:21 +0200, Aurélien Campéas wrote:
    > Le mercredi 22 juin 2005 à 16:05 +0100, Alan Chandler a écrit :
    > >
    >
    > For the record, the static typing in Java is acknowledged as one of the
    > worst imaginable (in short : it is mandatory but you have to go through
    > its backdoor (read : defeat it) all the time to make working programs).

    It still provides more static type support than completely
    dynamically-typed languages like Ruby and Python. And if you use
    "generics" as provided in Java 1.5+ then this problem is resolved.

    >
    > OTOH, Working programs have been written in dynamically typed languages
    > for ages. Yes, industrial strength programs (whetever that means).
    >
    > And I don't know any serious study about this topic. All we have is
    > anecdotal developper experience/opinions. But you will be able to judge
    > how important is static typing by yourself, again, when trying
    > ruby/python/lisp ...

    This mail list isn't really the proper venue for this discussion so I'll
    just make one reply then shut up. All the following is of course just my
    opinion.

    Ruby/Python are excellent languages where the developers on the project
    are experienced and talented.

    However this isn't usually the case with any "industrial scale"
    development; the normal corporate IT department has people with a wide
    range of abilities, and in that situation the support of a statically
    typed language can be very useful (IMO).

    And anyway it is *extremely* difficult to sell non-technical management
    on development in Ruby/Python. Java's marketing has, however, raised its
    awareness level to a point where the senior suits will actually consider
    it. So from a purely practical point of view, if you are interested in
    learning tools that will be of use in a commercial environment then Java
    is much more useful to know than Ruby/Python.

    >
    > There is an aspect of Java that is quite misunderstood : it is a good
    > language / platform not because of some technical merits (it is really a
    > rehash of 60's technology) but because of the division of labor it
    > allows in the industry (and some other "social" or "political"
    > properties) :
    > * separation from the designers (or so-called software architects) that
    > draw UML pictures and the coders (so-called code-monkeys that do the
    > supposedly unintelligent translation from high-level pictures to PL
    > level)
    > * mass availability of Java programmers (thus supposed
    > interchangeability of those)
    > * good marketing pressure from Sun and other big players to make Java
    > the new COBOL
    >
    > All the hype about Java being an OO-language (a very poor one indeed)
    > and bringing encapsulation to programming in the large masks the fact
    > that the big organizations that use Java need to encapsulate, indeed,
    > the many mediocre (read : insufficiently trained on theoretical and
    > practical levels, thus cheaper) programmers that make their huge dev.
    > teams.

    I pretty much agree with this. Java is a middle-of-the-road compromise
    language. I don't think it's "a very poor" OO language, it's an average
    one. The only revolutionary thing about Java is the fact that it
    compiles to portable bytecode (well, it isn't actually the first to do
    that either). But, in a twist of fate, in Java's "server" niche that is
    almost irrelevant.

    And J2EE was horribly over-complicated, a fine example of
    design-by-committee. However under pressure from alternative
    nicely-designed frameworks like Spring and Hibernate, J2EE is becoming
    more streamlined and easier to use. J2EE 1.5 should be a significant
    improvement over the past. The servlet spec was always a nicer beast,
    simple and focussed, and hasn't changed much since its first release.

    And the Java language underlies all of these.

    Re Tomcat/JBoss: applications should always be separated into
    "presentation" and "business logic" parts. This allows experts on the
    "business logic" to work on parts without being concerned about how
    exactly the information is presented to the user. And it means that the
    presentation can be updated/modified without any concerns about breaking
    the critical business logic. In large industrial systems, "business
    logic" is implemented as a set of "Enterprise Java Beans" (EJBs). And
    the presentation is implemented as servlets/jsp-pages. Sun have
    published separate specifications for these two parts: the servlet spec
    and the ejb spec. And the two combined is called "j2ee". Tomcat
    implements only the "servlet" spec. JBoss implements the EJB support
    stuff itself, and incorporates Tomcat to deal with the servlet part (or
    Jetty which also is a project that just implements the servlet spec).

    However where there is little/no critical business logic in an
    application it is possible to use just the servlet level functionality
    to implement the application. So Tomcat (or Jetty or other) can be used
    on its own. And that is probably where you want to start - servlets are
    not trivial, but EJBs can be very complex to use.

    Anyway, you should probably start by buying a book on servlet
    development which will discuss all of this.

    Other sites you may wish to investigate:
      http://myfaces.apache.org/
      http://struts.apache.org/
      http://jakarta.apache.org/tapestry/
      http://incubator.apache.org/beehive/

    NB: the large number of frameworks that exist to "simplify" servlets and
    EJBs may be taken as an indication that the original specs weren't
    entirely up-to-scratch...

    Regards,

    Simon 

    -- 
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
  • Next message: Roberto C. Sanchez: "Re: apt-get install won't recover from removal of apache directory in /etc/"

    Relevant Pages

    • Re: type checking
      ... Either Java, C# or Delphi may be a good option for you. ... to give you the same productivity as Python. ... if you're REALLY keen for static typing you owe it to yourself ... a good dynamic-typing language, then moving to a good static-typing ...
      (comp.lang.python)
    • Re: Client-Server to Web App
      ... it possible to keep a connection open to the C++ server between ... The downside is if the C/C++ server side piece is not thread safe. ... Below is a Java ... If you called this class from a standard Java Servlet, for instance, since ...
      (borland.public.delphi.non-technical)
    • Re: Velocity
      ... > If he asks me to go deep into java, there is something I need to know. ... suggest "Java Servlet Programming" by Jason Hunter, ... Finally, if you're going to do any Struts programming at all, ... you should seriously consider installing an IDE such as Eclipse ...
      (comp.lang.java.programmer)
    • Re: Java Servlet counterpart in .Net?
      ... John Timney (MVP) ... wich I can create a web application and decide if I will deploy it on Java ... The closest you probably have to a true servlet is the code behind model ...
      (microsoft.public.dotnet.framework.aspnet)
    • Re: Servlet To Java Application Communication
      ... I would like to write a Java servlet that it will be able to ... way to communicate with a servlet. ... probably know you should encode the request XML in the body part of a POST ... and expect the response XML in the response content. ...
      (comp.lang.java.databases)