Re: Setting up a Java development environment the debian way.
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
Reply to: