Learning Java

[Steve Graham]

I've been a programmer for 3 decades working in mostly procedural
languages, although I have done some work with a couple of
object-oriented ones.

Which book would you recommend that I read to learn Java? Obviously, I
don't want to read a beginning programming book, nor do I want to study
one which presupposes I know something about Java or a lot about OO
concepts.

Thanks, Steve

 

[markspace]

I've been a programmer for 3 decades working in mostly procedural
languages, although I have done some work with a couple of
object-oriented ones.

Which book would you recommend that I read to learn Java? Obviously, I
don't want to read a beginning programming book, nor do I want to study
one which presupposes I know something about Java or a lot about OO
concepts.

First, how is your object oriented programming skills? Java really only
provides OO options, so you're going to need to know OO decently.

To get started with Java itself, I recommend you start with the Oracle
tutorial. It's free and does a decent job.

<http://docs.oracle.com/javase/tutorial/>

Second, there are quite a few books. I like O'Reilly's Learning Java.
It starts as a basic introduction, but there's enough other information
in the book that will last you quite a while as a reference. It also
has one of the better explanations of Java's generics; that alone is
worth the price of the book imo.

There's also Effective Java, by Joshua Bloch. And Java Concurrency in
Practice by Brian Goetz for a well rounded treatment of multi-threading
in Java (very important these days).

I also took a programming course via javapassion.com. It's a pay-for
site now. But the course I took would have been well worth the price
they are asking now. If you're a busy professional who wants to come up
to speed more quickly, I recommend it as faster than trying to self-teach.

Beyond that... well my library is one whole bookcase of software
engineering best practice and methodologies, Java and otherwise. I have
several boxes in storage of books I didn't care for. It's a broad
field, and important to keep up with constantly.

 

[glen herrmannsfeldt]

You can do procedural programming in Java. You might find it easier
to start that way, to get used to Java, and then learn the OO stuff.

Read about static methods in any Java book, and you can pretty
easily write anything that you would in C. (It will even look
a lot like C.)

Java is much like C (to me, it is closer to C than C++ is).
If your 3 decades are in C, you should have an easy time learning
procedural Java.

Also, you can do OO programming in a procedural language, though
it isn't quite as easy. I knew OO programs in Fortran 66 (more than
three decades ago).

First, how is your object oriented programming skills?
Java really only provides OO options, so you're going to
need to know OO decently.

To get started with Java itself, I recommend you start with
the Oracle tutorial. It's free and does a decent job.

Second, there are quite a few books. I like O'Reilly's Learning Java.
It starts as a basic introduction, but there's enough other information
in the book that will last you quite a while as a reference. It also
has one of the better explanations of Java's generics; that alone is
worth the price of the book imo.

He can skip the chapters that are too easy, but should study
the OO parts, even if they are introductory.

(snip of more book discussion)

-- glen

 

[Arne Vajhøj]

You can do procedural programming in Java. You might find it easier
to start that way, to get used to Java, and then learn the OO stuff.

Read about static methods in any Java book, and you can pretty
easily write anything that you would in C. (It will even look
a lot like C.)

Java is much like C (to me, it is closer to C than C++ is).
If your 3 decades are in C, you should have an easy time learning
procedural Java.

He could.

But I would not recommend it.

If one is to learn Java, then one should use Java the Java way.

It will not utilize the language fully and it would puzzle all
maintenance programmer to use Java the C way.

Arne

 

[Arne Vajhøj]

I've been a programmer for 3 decades working in mostly procedural
languages, although I have done some work with a couple of
object-oriented ones.

Which book would you recommend that I read to learn Java? Obviously, I
don't want to read a beginning programming book, nor do I want to study
one which presupposes I know something about Java or a lot about OO
concepts.

I think you need a book like this one:

http://www.wrox.com/WileyCDA/WroxTitle/Professional-Java-JDK-6-Edition.productCd-0471777102.html

Note that I do not know the specific book, but other of
Wrox'es "Professional Xxxxx" are good.

Arne

 

[markspace]

You can do procedural programming in Java. You might find it easier
to start that way, to get used to Java, and then learn the OO stuff.

I have to concur with Arne and wouldn't recommend that either. I asked
how his OO comfort level was for a reason. If it's nil, he should also
study OO along with Java. If it's average to fair, he'll probably be fine.

Some specifics from the OP about what level of OOP he is comfortable
with would help us with further recommendations. (What books has he
read, what has he done, etc.)

 

[Arved Sandstrom]

You can do procedural programming in Java. You might find it easier
to start that way, to get used to Java, and then learn the OO stuff.

I suspect that a cold, hard analysis of all Java code written in the
past 15 years would show that the large majority of it _is_ procedural.

Fact is, Java and Objective-C and C++, to name a few OOP languages, are
generally used to write substantially imperative code, where procedures
appear as object methods. We may as well not ignore that, it's what most
OO programmers do.

Having said that, the advantage of objects and OOP shouldn't be
discounted. We simply shouldn't pretend that modern OOP isn't still
largely imperative/procedural code. If we advise the OP to learn proper
OO - and I certainly do - the fact is that in his studies he's going to
come across a stupendous amount of imperative Java. I recommend that the
OP keep this in mind. There are fine resources available for learning
the principles and theory of OOP; one simply has to remember that much
real-world code deviates substantially.
[ SNIP ]

AHS

 

[Arne Vajhøj]

I suspect that a cold, hard analysis of all Java code written in the
past 15 years would show that the large majority of it _is_ procedural.

Fact is, Java and Objective-C and C++, to name a few OOP languages, are
generally used to write substantially imperative code, where procedures
appear as object methods. We may as well not ignore that, it's what most
OO programmers do.

Having said that, the advantage of objects and OOP shouldn't be
discounted. We simply shouldn't pretend that modern OOP isn't still
largely imperative/procedural code. If we advise the OP to learn proper
OO - and I certainly do - the fact is that in his studies he's going to
come across a stupendous amount of imperative Java. I recommend that the
OP keep this in mind. There are fine resources available for learning
the principles and theory of OOP; one simply has to remember that much
real-world code deviates substantially.

OOP is supposed to be imperative, so I do not see much point in that
argument.

How big a portion of Java code that is procedural will depend a
bit on where you put the bar.

If we put the bar relative low:
procedural = all static methods
OOP = use of interfaces, private fields public methods
then the majority of Java code is not procedural.

Arne

 

[glen herrmannsfeldt]

(snip, I wrote)

I have to concur with Arne and wouldn't recommend that either. I asked
how his OO comfort level was for a reason. If it's nil, he should also
study OO along with Java. If it's average to fair, he'll probably be fine.

I think it depends. OP didn't say which language(s) were used over
those decades. It might make a difference. Also, it might just be
too discouraging. Starting out procedural, one can use the ideas
one knows while learning the Java specific parts.

Some specifics from the OP about what level of OOP he is comfortable
with would help us with further recommendations. (What books has he
read, what has he done, etc.)

I suppose, but maybe also why he wants to learn Java.

-- glen

 

[Stefan Ram]

Java is much like C

Here is an example C code (an untested library)
to be translated to Java:

#include <stdio.h>

int open
( const char * const path,
const char * const mode,
double( *continuation )( FILE *, void * ),
double( *error )( int, int ),
void * data )
{ FILE * const file = fopen( path, mode );
int result = 0; int status;
if( !file )result |= 1; else
{ if( status = continuation( file, data ))result |= 2;
if( fclose( file ))result |= 4; }
if( result )
{ if( error( result, status ))result |= 8; }
return result; }

 

[Arved Sandstrom]

OOP is supposed to be imperative, so I do not see much point in that
argument.

OOP isn't "supposed" to be imperative at all, it just happens that most
mainstream OO languages are. C++, Objective-C, Java etc, those are
imperative OO languages. But you can and do have languages that are
functional and use OO, even some that are logical and have elements of OO.

To the extent that OO != imperative I don't withdraw my use of the term
"imperative". But I really meant "procedural", and should have used that
across the board.

However, let's stick to the imperative OO languages here. My argument is
that a great deal of actual (non-teaching) Java code strays
substantially from best-practice OO, and is best characterized as
"procedural" and/or "structured" and/or "modular". It doesn't really
have those extra features that distinguish good OO code.

That is the main argument I am making. And it's about "what is", as a
caution to the OP, not a reflection on the best Java or even decent Java
that can be written by a programmer who is reasonably well-grounded in
proper OO. I am pointing out what we often see.

How big a portion of Java code that is procedural will depend a
bit on where you put the bar.

If we put the bar relative low:
procedural = all static methods
OOP = use of interfaces, private fields public methods
then the majority of Java code is not procedural.

Arne

That's a very low bar, and it's selected to make a lot of Java and C#
real-world code look good. By that criterion all those large instance
methods out there that gather in a multitude of behavior-anemic objects
and perform algorithms on them are OOP. Well, of course they are
technically OOP.

What's the most classic "procedure" that Java has? The "main" method in
a main class. That's even one by your definition. Often what people do
in "main" is call the constructor of the main class, and invoke an
instance method on it that is the top-level "procedure". Not too much
really OO-like about that at all.

Let's consider Java EE. No small number of web apps have a fat "service"
or "application" layer that teems with procedural code. Session beans
and managed beans are loaded with large methods that, despite being
instance methods, are "procedures" that assemble a variety of
data-holder objects (not really interesting domain objects at all, not
by classic domain/model design they're not) and invoke logic on those
objects in an algorithmic way: mostly logic that ought to have been in
the "domain" objects. Even where some of the "procedural" code has been
subdivided to make it appear more OO-like, and is parcelled out to
"domain" objects to make them look better, it's awkward and forced.

Your definition would have it that all the instance code in this latter
category is non-procedural. Again, _technically_ it's OO. But that's
really stretching it.

I can almost hear Lew chiming in. To forestall that, I'll reiterate, I'm
pointing out to the OP that when inspecting _real_ Java that he should
be careful about what's good OO and what is merely *technically* OO.

AHS

 

[Lew]

I can almost hear Lew chiming in. To forestall that, I'll reiterate, I'm
pointing out to the OP that when inspecting _real_ Java that he should
be careful about what's good OO and what is merely *technically* OO.

Far be it from me to disappoint my fans.

Arved's right, in that by a distinguishing definition of object-oriented. that is, one that sets it apart from "pre-"object-oriented styles, much Javacode in the real world is not OO. The trivial definition, Arved's “merely *technically* OO”, doesn't much help one distinguish not very OO from very OO.

The question is, "So what?"

So, "OO" shouldn't be a religion, but a measuring stick to help evaluate code quality. What we're really after here are best practices to organize code so that it's bug free, provably correct, inexpensively maintainable and magically satisfying to the customer. Taken together, such practices result in something arguably "object oriented" irrespective of source language.

But your object orientation is only ever as good as your analysis, and yourimplementation strategy to reduce state coupling and cogent modeling of the problem domain.

Same as procedural code that way.

So avoid the sorts of sins Arved described ("God classes", spaghetti code disguised as methods and so on), be aware of the valid (non-buzzwordy) virtues of OO, or generally of good code, and cast a jaundiced eye on real-worldcode and pedagogical examples alike.

Thanks for making the distinction, Arved.

 

[Lew]

But your object orientation is only ever as good as your analysis, and your implementation
strategy to reduce state coupling and cogent modeling of the problem domain.

er, reduce coupling and *improve* cogent modeling. (Abashed grin)

 

[glen herrmannsfeldt]

(snip, someone wrote)

OOP isn't "supposed" to be imperative at all, it just happens that most
mainstream OO languages are. C++, Objective-C, Java etc, those are
imperative OO languages. But you can and do have languages that are
functional and use OO, even some that are logical and have elements of OO.

But also, I believe, that there is an appropriate amount of OO-ness.

Especially for computationally intensive algorithms, the inner loops
should avoid creation of objects. Like just about everything, OO
can be over done.

To the extent that OO != imperative I don't withdraw my use of the term
"imperative". But I really meant "procedural", and should have used that
across the board.

However, let's stick to the imperative OO languages here. My argument is
that a great deal of actual (non-teaching) Java code strays
substantially from best-practice OO, and is best characterized as
"procedural" and/or "structured" and/or "modular". It doesn't really
have those extra features that distinguish good OO code.

Well, first of all, as I understand it the big advantage of OO is
readability. But even so, too much of a good thing isn't always good.
If something is more readable in procedural form, then do it that way!

There are procedures (usually in non-OO languages) that are thousands,
maybe tens of thousands of lines long. But there is a size that is
easily understood by a good programmer, maybe in the 100 line range,
and one shouldn't necessarily get smaller than that, just for OO sake.

Now, the other reason for OO is for extensibility, and sometimes
that will require an object where it otherwise might not be needed.

That is the main argument I am making. And it's about "what is", as a
caution to the OP, not a reflection on the best Java or even decent Java
that can be written by a programmer who is reasonably well-grounded in
proper OO. I am pointing out what we often see.

-- glen

 

[Gene Wirchenko]

On Wed, 18 Apr 2012 07:11:56 -0300, Arved Sandstrom

[snip]

However, let's stick to the imperative OO languages here. My argument is
that a great deal of actual (non-teaching) Java code strays
substantially from best-practice OO, and is best characterized as
"procedural" and/or "structured" and/or "modular". It doesn't really
have those extra features that distinguish good OO code.

"Look, kitty! Pigeons!" [toss]

All methods are procedural. The big deal about OO is how they
are called.

OO can be very useful. It can also lead to horrible clutter.
Just because I have OO in my arsenal does not mean that I have to use
it. (The same thing applies to any tool. Sometimes, it is a good
idea to use the tool, and sometime, something else is more
appropriate.)

[snip]

Sincerely,

Gene Wirchenko

 

[RedGrittyBrick]

You can do procedural programming in Java. You might find it easier
to start that way, to get used to Java, and then learn the OO stuff.

I'd strongly advise against this. An awful lot of Java programming
consists of using the standard libraries. To do so effectively I really
think you have to start by learning Java OO.

There is an O'Reilly book called "Learning Java". I found it helpful.
The online resources referred to by others are also good for initial
learning. The other books suggested (Effective Java, Java Concurrency)
are very good but I'd suggest not starting with them (don't delay
reading them too long either)

Just my ¤0.02 worth.

 

[Roedy Green]

I've been a programmer for 3 decades working in mostly procedural
languages, although I have done some work with a couple of
object-oriented ones.

see http://mindprod.com/jgloss/gettingstarted.html
--
Roedy Green Canadian Mind Products
http://mindprod.com
When you were a child, if you did your own experiment
to see if it was better to put to cocoa into your cup first
or the hot milk first, then you likely have the programmer gene..

 

[Arne Vajhøj]

I think it depends. OP didn't say which language(s) were used over
those decades. It might make a difference. Also, it might just be
too discouraging. Starting out procedural, one can use the ideas
one knows while learning the Java specific parts.

But what benefit would it have? Learning to code Fortran/C in
Java is not a particular useful skill!

Arne

 

[Arne Vajhøj]

OOP isn't "supposed" to be imperative at all, it just happens that most
mainstream OO languages are. C++, Objective-C, Java etc, those are
imperative OO languages. But you can and do have languages that are
functional and use OO, even some that are logical and have elements of OO.

To the extent that OO != imperative I don't withdraw my use of the term
"imperative". But I really meant "procedural", and should have used that
across the board.

However, let's stick to the imperative OO languages here. My argument is
that a great deal of actual (non-teaching) Java code strays
substantially from best-practice OO, and is best characterized as
"procedural" and/or "structured" and/or "modular". It doesn't really
have those extra features that distinguish good OO code.

That is the main argument I am making. And it's about "what is", as a
caution to the OP, not a reflection on the best Java or even decent Java
that can be written by a programmer who is reasonably well-grounded in
proper OO. I am pointing out what we often see.

That's a very low bar, and it's selected to make a lot of Java and C#
real-world code look good. By that criterion all those large instance
methods out there that gather in a multitude of behavior-anemic objects
and perform algorithms on them are OOP. Well, of course they are
technically OOP.

What's the most classic "procedure" that Java has? The "main" method in
a main class. That's even one by your definition. Often what people do
in "main" is call the constructor of the main class, and invoke an
instance method on it that is the top-level "procedure". Not too much
really OO-like about that at all.

Let's consider Java EE. No small number of web apps have a fat "service"
or "application" layer that teems with procedural code. Session beans
and managed beans are loaded with large methods that, despite being
instance methods, are "procedures" that assemble a variety of
data-holder objects (not really interesting domain objects at all, not
by classic domain/model design they're not) and invoke logic on those
objects in an algorithmic way: mostly logic that ought to have been in
the "domain" objects. Even where some of the "procedural" code has been
subdivided to make it appear more OO-like, and is parcelled out to
"domain" objects to make them look better, it's awkward and forced.

Your definition would have it that all the instance code in this latter
category is non-procedural. Again, _technically_ it's OO. But that's
really stretching it.

I wrote:
procedural = all static methods
OOP = use of interfaces, private fields public methods

It seems as if you are mostly arguing based on:
procedural = some static methods

I don't think the presence of some static methods is anti-OO.
Several patterns from the GoF book uses static methods.

And I do not agree with the service methods plus data classes
not being OOP argument either.

Back in the 90's good OOP was rich classes with both methods
and data.

Today good OOP is more focused on the encapsulation aspects
(which was my second bullet point).

The 90's good OOP is now called "rich domain model".

One of the main drivers behind the change IMHO is that it became
clear that not everything was a good fit for traditional model. There
are simply needs for different focus on data versus method: some
classes are method heavy, some classes are a more even mix
and some classes are data heavy.

Encapsulation is used in almost all Java EE apps, because
Java EE is designed over these concepts and so are much of
the supplementary stuff like Hibernate (non JPA API),
Spring etc..

Arne

 

[Arved Sandstrom]

I wrote:
procedural = all static methods
OOP = use of interfaces, private fields public methods

It seems as if you are mostly arguing based on:
procedural = some static methods

I don't think the presence of some static methods is anti-OO.
Several patterns from the GoF book uses static methods.

You're pushing me too far over to one side when you characterize my
arguments. So far I've said little about static methods - I've been
noting the misuse of instance methods. I've focused deliberately on
instance methods because it is easier to disguise their misuse.

As far as static methods go, I don't think the use of *some* static
methods is bad either. They are inherently procedural, however. You
acknowledged that to some degree when you equated 'procedural = all
static'. I happen to think that the bar should be lower, that the more
of your code that you've jammed into static methods the more procedural
your code has become. There's no 0/100 black/white here.

I prefer static methods that are non-business-logic implementation
details, if you've got to use them at all. Like static factory methods.

And I do not agree with the service methods plus data classes
not being OOP argument either.

It's OOP. It's _technically_ OOP. More discussion below.

Back in the 90's good OOP was rich classes with both methods
and data.

Not always "good" OOP. Let's just call that "1990's OOP" or "1990's
accepted OOP".

Today good OOP is more focused on the encapsulation aspects
(which was my second bullet point).

The 90's good OOP is now called "rich domain model".

One of the main drivers behind the change IMHO is that it became
clear that not everything was a good fit for traditional model. There
are simply needs for different focus on data versus method: some
classes are method heavy, some classes are a more even mix
and some classes are data heavy.

That's exactly right: it became clear that the "emergent" premise behind
the rich domain model typically failed. People invariably had a
difficult time deciding where to put all their logic, because much of it
did not neatly belong to any one domain class. That led either to
abstract and dubious domain classes for the purpose of holding methods
that had no better home, or drove that change you referred to above (and
which I've criticized): creating lots of service classes in an
application layer, where this difficult-to-place logic gets put as
instance methods.

As a short-term response to the flaws inherent in the rich domain model
I have no serious problems with that change. A great deal of logic _is_
procedural, and you should code it up that way. But let's not call it
OO. My argument is just that, that a lot of Java code is procedural. I'm
not saying it's awful. When I previously used language like "ought to
have been", I'm saying that in reference to what you'd strive for with
classic, rich domain model OO.

This is my point exactly: that this change to lots of procedural, for
basically good reasons, has happened in Java (and other class-oriented
languages like C#). What is a problem is that people continue to insist
that this procedural code isn't.

I've mentioned DCI numerous times before: it is precisely an effort to
put some formalism and structure into how one deals with this
algorithmic/procedural code in an OO environment.

Encapsulation is used in almost all Java EE apps, because
Java EE is designed over these concepts and so are much of
the supplementary stuff like Hibernate (non JPA API),
Spring etc..

Arne

Encapsulation is great. I don't care if one class is basically a struct
(Java Bean) and another is a domain class loaded with behaviour - they
all have their place. Encapsulation enters into all of that.

However, the argument here is about where a lot of the procedural logic
goes. The attempt to keep it all in domain classes failed a long time
ago. People have adjusted, often quite well. What's been missing is a
general acknowledgement that we write a *lot* of procedural Java code,
and maybe work on ways to formalize how to do that well. DCI is one
approach.

AHS