new String ( byte[] , encoding ) under the hood

[Roedy Green]

Actually, HotSpot ignores the final flag (although a few methods are
recognised as intrinsics, which may make a difference). And it's quite
happy to inline code called through interfaces.

But then if someone later overrides the non final code, it has to go
into a panic, stop everything,and regenerate all optimised machine
code that calls the overridden class. It can no longer inline the code
it was presuming was for them moment as if final.

 

[Andrew McDonagh]

So where should such methods go?

What are the disadvantages of putting them on String?

it doesn't conform to SRP or LoD for a start...

Coding convenience having all the methods at hand for String is a big
plus.

No, a good IDE and a better design does this for us, not simplified,
fragile, everything-in-one-bucket designs.

 

[Mike Schilling]

That doesn't explain why StringBuilder is final.

There are other security reasons for requiring final. Say I had a security
conscious class and I allowed some method that took a StringBuilder and
appended some private objects to it. Now imagine someone malicious comes
along and overrides StringBuilder.append(Object). Malicious code now has
access to my sensitive object.

As opposed to having access to their text representations through normal
StringBuilder behavior?

 

[Chris Uppal]

it doesn't conform to SRP or LoD for a start...

Can you state what the "single responsibility" of String /should/ be. I can't.
It seems to me to be a general purpose class, and it's principle design
criterion should be convernience for the user.

And what does the Occasionally Good Advice of Demeter have to do with it ?

-- chris

 

[Chris Uppal]

The Java designers wanted String to be immutable, and this is
probably the reason it is final. Same with Integer, etc.

I agree that immutability is a worthwhile design goal. I don't think that
/guaranteed/ immutability is worth the price of making String (and pals) final.
If such a facility was required (as it might well be) then that could have been
implemented by a final subclass of String (which inherited String's immutable
API, and was final in order to lock that down). I'd have been tempted to use
the ImmutableString subclass for the values of String literals.

-- chris

 

[Chris Uppal]

Mike Schilling wrote:

[me:]

As opposed to System.out and Exception.printStackTrace(Writer)

<grin/>

Um, well... Yes.

I'll agree that Exception.printStackTrace() is, er, unfortunate. I'm less
bothered by System.out. String, like Object, and Class is one of the classes
that is needed just in order to describe the Java language and semantics, as
opposed to being merely part of the Java platform (for instance, they need
special treatment during bootstrapping). Unfortunately, for that argument, so
is Throwable...

-- chris

 

[Chris Uppal]

There are other security reasons for requiring final. Say I had a
security conscious class and I allowed some method that took a
StringBuilder and appended some private objects to it. Now imagine
someone malicious comes along and overrides
StringBuilder.append(Object).

So the hypothetical security-conscious code should use toString() explicitly
before appending the data. I'm not saying you are wrong about Sun's reasons,
but the whole thing seems to be part and parcel with the design error of making
String final. Very little code /is/ security-conscious, and what there is
tends to be anything but trivial. Making String (and pals) significantly less
flexible for everyone is a bad bargain if all that's gained is that some
complicated and difficult code is marginally less complicated and difficult.

-- chris

 

[Thomas Hawtin]

Very little code /is/ security-conscious,

That is a big problem.

Tom Hawtin

 

[Chris Uppal]

That is a big problem.

A lot depends on what exactly we are talking about when we say
"security-conscious". If we mean that there is (far) too much code written
with (far) too little thought for security against /external/ attacks --
basically against hostile input -- then I agree whole-heartedly[*]. But if we
are (as I thought we were) discussing security against other code running on
the same JVM, then I'm much less sure. My impression is that it's rare to have
to protect one's code against attack by -- say -- hostile subclasses, yet it's
that broad category of protection that the finality of String (and pals) seems
to be aimed at.

-- chris

([*] and no, I don't claim to be specially good at it myself, though I'm not a
total looser. Secure coding is something that comes with practise, feedback,
and constant attention, and I've had too little practise and almost no
feedback.)

 

[Mike Schilling]

Mike Schilling wrote:

[me:]

As opposed to System.out and Exception.printStackTrace(Writer)

<grin/>

Um, well... Yes.

I'll agree that Exception.printStackTrace() is, er, unfortunate. I'm less
bothered by System.out. String, like Object, and Class is one of the
classes
that is needed just in order to describe the Java language and semantics,
as
opposed to being merely part of the Java platform (for instance, they need
special treatment during bootstrapping). Unfortunately, for that
argument, so
is Throwable...

While Reader is part of java.io, a Reader is, essentially, a source of chars
(and might not do any IO e.g. StringReader). It makes perfect sense to me
to be able to constrct a String from a source or chars. If it would make
you feel better to create an interface java.lang.CharacterSource which is a
superinterface of Reader, it's OK with me

 

[Chris Uppal]

While Reader is part of java.io, a Reader is, essentially, a source of
chars (and might not do any IO e.g. StringReader). It makes perfect
sense to me to be able to constrct a String from a source or chars.

I agree. It was (and is) only the inverted dependency link that offends.

If
it would make you feel better to create an interface
java.lang.CharacterSource which is a superinterface of Reader, it's OK
with me

I'd settle for that ;-)

Tempting to suggest a String constructor that takes an
Iterator<Character>
or -- to follow Sun guidelines -- an
Iterable<Character>

But that would be horrendously inefficient, and would futher promulgate the
myth that Java's char type corresponds to Unicode characters. Perhaps, for
both reasons, a constructor taking an
Iterable<char[]>
would be better.

-- chris

 

[Chris Smith]

And what does the Occasionally Good Advice of Demeter have to do with it ?

Wow, I thought I was the only person who considers that to be
overstated. Everyone else seems so caught up with it...

Nevertheless, I assumed Andrew meant "Levels of Detail", a term which is
commonly used in 3D modeling but I've seen applied metaphorically to
programming. Of course, it would help if Andrew would actually say what
he means.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Uppal]

Chris Smith wrote:

[me:]

Wow, I thought I was the only person who considers that to be
overstated. Everyone else seems so caught up with it...

It does seem to get more attention than it warrants (even conceding its --
inflated, IMO -- value). I assume that's the result of having a Cool Name
(tm).

Nevertheless, I assumed Andrew meant "Levels of Detail", a term which is
commonly used in 3D modeling but I've seen applied metaphorically to
programming.

I suppose that is a possibility too. Not sure I see the applicability, even
so...

-- chris