Inserting In a List

[Robert Klemme]

On 05/04/13 21:33, Lew wrote:
lipska the kat wrote:
Stefan Ram wrote:
Arved Sandstrom writes:
Stefan Ram wrote:
Arved Sandstrom writes:

[snip]

What is C? We have pointers in Java, see the JLS.

Do we? I never knew that

It's in the JLS, 4.3.1.
"An object is a class instance or an array.

"The reference values (often just references) are pointers to these
objects,
and a special null reference, which refers to no object."

This is a rhetorical usage of the word pointer and says nothing about
the underlying mechanism used to implement references.

Why "rhetorical"?

The Java Language Specification is just that, a specification.
Constraining an implementation to use *pointers is not within the
purview of the specification, this is why I suggested that the usage is
rhetorical.

I don't think it is constraining implementations - it merely uses
"pointer" with a different meaning (suggestion: "something that points
to something") than the one you have in mind and which is used commonly
in CS.

and why? There is nothing weaselish about quoting the JLS.

I'd be very interested to see the line in the spec that says

'It [Java] only has pointers for reference types'

Show me that and watch me eat my hat.

Can we skip the "show" part and directly go to "eat my hat"? ;-)

Of course it is, how could I possibly imagine that it could ever be
otherwise.

See? ;-)

Although ... actually, forget it, it really isn't that important, the
sun is shining and I have seeds to sow, the lawn to cut and frogs to
watch in the pond.

I'll send our cat over. Here it's still uncomfortably cold (although
getting better) and she prefers to stay in an demonstrate her bad temper...

Cheers

robert

 

[Arved Sandstrom]

On 06/04/13 16:50, Robert Klemme wrote:

[ SNIP ]

Bloody cats, crapping in my veg beds, digging up my seedlings, hissing
and howling and sitting by the pond pulling the pond weed out with their
paws trying to get at the frogs.

Grrrrrrrrrrrrrrr

lipska

Don't hold back. How do you really feel about cats?

AHS

 

[markspace]

I think there's too much mixed here. "Thread safety" and
"(im)mutability" are two different concepts. They are orthogonal -

That's fair. I definitely over-sold the case between thread-safety in
general and immutability in that post you quoted. There's other ways of
achieving thread-safety than immutability. I was going fast and not
thinking thoroughly about what I typed.

But thread-safety and immutability are not orthogonal. Immutable
objects are all thread-safe. I urge you to re-read the section in JCIP
starting on page 46 that talks about immutability. Brain Goetz says
explicitly that immutability in Java requires final fields.

(He then makes an exception to that in a footnote, but I think we're all
quibbling too much over basic terms and understanding final fields to go
looking for sneaky ways around final fields.)

Later, after everybody's on the same page with respect to final fields,
we might talk about ways we don't need them. But I think we have to get
final field semantics down first or the discussion will be a mess.

First of all, objects which are mutable can be thread safe - it depends
on their implementation. (J?rg pointed that out already).

Yup, I missed that concept when I made my statement above. Mea culpa.

But: that does not necessarily constitute thread safety. An immutable
object can still be implemented in a thread unsafe manner. For example:

Well, there's safety and then there's other concepts related to
concurrency. I think it's best not to lump all concurrency related
discussion under the term "safety". What you showed was more a matter
of atomicity and mutex. So it might be better to use more specific
terms when describing it.

Here's another:

public final class OopsPrinter {
private final PrintStream out;
public KeyValuePairPrinter(PrintStream out) {
this.out = out;
}

/**
* Prints to a special PrintStream
*/
public void print(Object key, Object value) {

PrintStream save = System.out;
System.setOut( this.out );
System.out.printf( "blah blah etc." );
System.setOut( save );

}
}

I'd call this "global interference." Any thread calling this method
will set a global variable that affects all threads in the entire
system. It's safe because the JVM handles writes to System.out
specially so they are thread safe, but any other thread using System.out
at the same time as this method is executing will get a surprise. Brian
Goetz calls this "thread hostile."

("Interference" is a technical word used in a lot of literature on
concurrency, which I've run across before. It basically means a race
condition of some sort.)

 

[Robert Klemme]

e) Adding parameters to methods is a code smell, each "final" keyword
augments that by growing the signature even faster. I find it funny,
that one of the biggest design mistakes in the language (no final
default) is actually of some benefit here.

Once you always use "final" where appropriate, and became used to it,
the visual clutter starts to disappear.

Which goes a bit against item e. ;-) I do agree with all your other
points. Put much better than I did it before.

Cheers

robert

 

[Lew]

In my opinion it's been an unfortunate decision to have a "final"
keyword instead of a "var" keyword with a "final" default.

I respect that opinion but I hold it not, mostly because I came to Java after it
was invented and didn't have any say in the matter.

Now, I'm a fan of using the "final" keyword everywhere possible apart
from method and class declarations and I'll give you my reasons behind
it.

However, I do hold that this style is, formally, desirable.

Except you should use it on method and class declarations, too. As Bloch says,
you should design for heritability or prevent it.

a) It expresses more exactly what the code really does. I think that a
certain precision of expression is of beauty. This is a rather stylistic
view.

Indeed, it is a style view, and everywhere I've worked has also had a style view.

b) As soon as you're used to having every possible assignment declared
"final", each missing "final" will stand out like an alarm sign - you
immedeately spot those assignments that change their value. It greatly
helps me understand the code. So it is of practical value, once you're
used to it.

Defensive programming is a defensible practice.

Detractors should understand that there is nothing of "helping the compiler"
about this. These are all justifications of semantics, and therefore relevant.

c) If I mistakingly (mistyping, code completion errs) assign a value to
a "final" reference, the compiler will warn me immediately. Since I
always declare "final" what is never intended to change, this stops me
from making stupid mistakes. I find this is of a hugepractical value.

It's part of the larger strategy of getting the compiler to do as much work for you
as possible.

My twisted mind says that Java's lack of runtime generics is an asset in this regard.
It forces the programmer to work much harder to get the type semantics correct at
compile time, and yes, oh, dear, to use an explicit run-time type token (RTTT) when
runtime genericity is de rigueur. But then at least you have whatever type assertions
possible handled by the compiler.

Okay, yes, I would appreciate runtime generics, but it's still a good idea to push things
to compile time.

d) I hardly have any problem with using a value in an anonymous class
and if I have, It tells me that I'm probably doing something stupid.

I think I get what you're saying here, but I'm not sure.

e) Adding parameters to methods is a code smell, each "final" keyword
augments that by growing the signature even faster. I find it funny,
that one of the biggest design mistakes in the language (no final
default) is actually of some benefit here.

It's a choice. I disagree that it's a mistake. At least you can put 'final'
everywhere, even though it's annoying that you must.

Once you always use "final" where appropriate, and became used to it,
the visual clutter starts to disappear.

I don't think the anti-'final'ists buy this one.

I don't agree that adding parameters to methods per se is code smell, but
it is not to be abused either. If you factor your model correctly you usually
don't create a whole lot of overloads, and those not too abundant. Anyway.

But you do add parameters when you need to, though pundits now suggest
using builders instead. That makes the use of a mutable type (sorry, purists)
explicit and temporary, which is usually right.

And again there are exceptions to the rule. It's like a rubber band - the farther
you get from rules of thumb like "keep parameters few and overloads fewer",
the greater the tension. It doesn't mean never do it, it does mean understand
that the tension is there for a reason, and you should minimize it.

Truly everywhere I work people would stick my head in the teapot like the
dormouse if I were to use 'final' like that. Like essay and paper publication,
there is a house style in every house. And it isn't really all that necessary
anyway.

Another rule of thumb is to keep methods short. In a short space you hardly
need 'final' to tell you not to change a local variable. You hardly have time
to use it once, let alone fear reassignment. So I cheerfully follow the seat-of-
the-pants crowd on this one.

 

[markspace]

public class Foo{
private int value;
private Foo(int value){this.value=value;}
public static Foo createFoo(int value){return new Foo(value);}
public int getValue(){return value;}
}

..is both immutable, thread safe and can't be overridden either, without

No, he doesn't say that, and no, this class isn't thread safe. Normal
POJO classes aren't thread safe. Adding a factory method doesn't help.

In order for this class to be thread safe 'value' would have to be made
visible somehow. You need volatile, a synchronized block, or something
similar. Please read the JLS (and JCIP, again) and note section 17
Threads and Locks. The whole point of that section is that regular
writes aren't thread safe.

If you'd like to point out where you think JCIP or the JLS says that the
above class is thread safe, I'll be happy to show what sections I think
say differently. At worst, one of us will learn something. ;-)

 

[Lew]

Huh! This is getting surreal, who is Bloch, it's you, at least I thought
it was, you're messing with my head, stop it.

Really? You are joking, no doubt, but just in case you aren't:

http://www.oracle.com/technetwork/java/effectivejava-136174.html
of course.

Your head is of no concern to me.

 

[Lew]

I do find the term "final variable" a bit clumsy though, because in my
view these are constants. Unfortunately in the Java world, we're calling
these "constants" only, if they're marked "static". Technically that's

That is not correct Java terminology. There is nothing in the Java definition
of "constant expression" or "constant variable" that requires a static context.

http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.28

http://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.12.4
"A variable of primitive type or type String, that is final and initializedwith a compile-time constant expression (?15.28), is called a constant variable."

It does not say "final, static and ...".

rather unfortunate, as these are just as "constant" as their non static
sisters - they're just forcibly the same for a wider scope (that of the
class loader).

Not so unfortunate in that the premise is incorrect:.

 

[Arved Sandstrom]

Well Java is an imperative language so let's go with that.


This is what I don't get, if it's a named bin that can be refilled why
do you _decorate_ it with final.

I'm probably not the most experienced developer here, 15 years and
counting with Java but I've done everything from Swing based desktop
stuff (yuk) to back end business applications that are presentation
layer agnostic, to state machines that communicate with hardware devices
and apart from one particular instance I can't think of a single time
that I have ever had to use final more than once or twice in a
component. Most components don't use it at all. What are you guys
*doing* that you feel the need to modify all your variables with final
everywhere. The whole point of a computer is to transform it's input to
some useful output, you store your input, transform it (by updating
variables usually) and emit it in a way that makes sense at that time.
If you want a functional language use Haskell (or whatever).

I may be missing something here but are you sure you are using the right
language?

lipska

Controlling the scope and extent of a variable is something you
absolutely want to do in imperative languages. One major reason for
doing that is to understand what can modify the variable, and to keep
those influences limited and manageable.

Logical extensions to that thinking - entirely logical in imperative,
not just in functional, programming - are to freeze the *variable* using
'final', so that you've got single assignment, or to freeze the *value*
using either object immutability (or const objects in languages that
support it). Or both.

I think you're exaggerating by implying that people feel the need to
make practically everything final. No, you make final what you expect
ought to be a read-only variable in its scope.

AHS

 

[John B. Matthews]

http://www.oracle.com/technetwork/java/effectivejava-136174.html

See also the old Sun Developer Network page:

<http://192.9.162.55/docs/books/effective/>

 

[Robert Klemme]

I'm probably not the most experienced developer here, 15 years and
counting with Java but I've done everything from Swing based desktop
stuff (yuk) to back end business applications that are presentation
layer agnostic, to state machines that communicate with hardware devices
and apart from one particular instance I can't think of a single time
that I have ever had to use final more than once or twice in a
component. Most components don't use it at all. What are you guys
*doing* that you feel the need to modify all your variables with final
everywhere.

As Arved I think "everywhere" is exaggerated. Some said they do it
habitually because they got used to it and found it useful. That
doesn't necessarily mean that every single item which could be
"finalized" is indeed.

The whole point of a computer is to transform it's input to
some useful output, you store your input, transform it (by updating
variables usually) and emit it in a way that makes sense at that time.

Making those things which are mutable to stand out vs. those which
aren't helps when there are a lot variables around.

One example: I had to modify a 600+ lines method (yeah, ugly). I
started with refactoring because otherwise I would have had zero chance
to fully understand what the code actually did. In the process I
started with moving variable declarations to the most restricted scope
and making things final. That helped my a great deal in understanding
the logic. Then I refactored appropriate parts into separate methods.
This is the kind of experience that led me to find "final" useful.

Kind regards

robert

 

[Robert Klemme]

On 08/04/13 07:28, Robert Klemme wrote:

I would be prepared to wager that when you had finished refactoring,
your method local variables were largely *not* final.

Was this the case ?

I really don't remember what the ratio of final vs. non final variables
was afterwards. But for example, foreach loop variable were indeed
final. Moving variables to smallest possible scopes also nicely helped
in finding a bug: there was a variable declared outside the loop and it
was obviously intended to be used during one iteration only but there
was a code path which allowed the last value to survive and be reused.

Kind regards

robert

 

[Lew]

Lew says...


compile-time constant expression (§15.28), is called a constant variable.">

Well, Lew, I guess you pretty much understand what I mean, it's the same thing.

I understood you to mean that to be called a "constant" in Java that the thing would
have to be static. That is not the same thing at all.

The term "constant variable" is a moronic oxymoron, it can be

Regardless of your emotional reaction to the term, that is the term.

either variable or constant. It's like saying "I have a fixed movable

The word "variable" in computer science does not mean "can vary". It means
"a named location that can hold a value."

device" - no, you haven't, you have a fixed device, by fixing it you
have removed the "movable" nature entirely.

It's nothing like that at all.

You yourself make this clear in another post:

"lipska the kat" says...

It's because it is not meant to be refilled, ever, that's what you call
a constant.

You are arguing both sides of the fence.

I might be used to the terminology used in the Eclipse IDE when you use
the refactoring "extract constant" you'll get a static final field.

"Extract constant" in Eclipse as a refactoring action does indeed extract to a
static constant variable.

That does not mean that static variables are the only ones that can be constant.
It just means that the wizard implements the common use case.

 

[Lew]

lipska the kat says...

It's because it is not meant to be refilled, ever, that's what you call
a constant.

It is not, however, what Java calls a "constant".

The point with 'final' is not that "it's a named bin that can be refilled",
so the reason the conclusion didn't follow is that the premise is false.

A variable is a named location that can be filled.

If it's 'final', it's explicitly a named location that *cannot* be refilled.