Reinier Zwitserloot wrote:
> You think it would make more sense if, to properly write java code,
> you really need to be intimately familiar with the vagaries of the JVM
> itself? You think it would still be acceptable that the requirements
> for a JVM remain as vague as they are now on how they work internally?
> You think that back in the day (java 1.0/oak), gosling and company
> would have had the vision to not add to the spec a large set of chains
> that would have made our current speedy hotspot compilers virtually
> impossible to write - given that it is now apparently required as a
> potential java programmer to know how it all works, and you're
> supposed to rely on this information?
>
> Just... no.
>
Gee, no as an answer is so closed and so final.. sometimes it's the
right answer but more often it cuts off paths of exploration. I would
rather explore.
There are some things you can do in your code that will help any
existing versions of the optimizing JVM and will help any versions to
come unless there is a radical depature from the current development
path. Just follow the hotspot mailing list to get a sense of where
things are going. I'll name two for starters. Small methods are easier
to optimize than larger ones. For example, smaller methods are better
candidates for method in-lining. Variables that are narrowly scoped have
a fair cheaper life-cycle than those with medium life-cycles. The
appearance of G1 doesn't appear to change this equation.
> Why don't you elaborate with some examples of what a non-final String
> class could have brought us? The vast majority of use cases I come up
> with involve automatic state transitions, where for example a method
> wants to url-encode everything that comes in, unless its already url-
> encoded. Therefore, it wants to know if the passed in string has the
> 'I am URL encoded' property, and if not, run it through another method
> which turns strings that don't have the 'I am url encoded' property
> into strings that do have it (by encoding it). At the same time, the
> way that method uses a string, is to ask for the raw format, which any
> 'encoded' string knows how to get to, by decoding itself.
>
maybe polymorphism could be a good solution. That is how we managed it
in Smalltalk.
> - it has to pick
> one, which is an obvious code smell.
>
polymorphically???
> Strings are one of those near-primitives in java: They get passed
> around all the time across all sorts of API boundaries.
>
which is the primary reason that the class (not the internal value)
should not have been declared final, it eliminated the possibility
properly use polymorphisum. Yes in this case it *is* the magic bullet ;-)
> Then there's stuff like SecurityMonitor and security-conscious
> applications, like mass-hosted web-apps, where mutating strings can be
> used maliciously
I feel that I'm battling the final class is not final variable confusion.
Here is an implementation of some final class
package com.kodewerk;
final public class MyString {
String state;
public MyString() {
}
public void setString( String newString) {
this.state = newString;
}
public String toString() {
return this.state;
}
}
so here is a class that can use it in another package
package com;
final public class Main {
String state;
public static void main(String[] args) {
MyString s = new MyString();
s.setString( "hello");
s.setString("world");
}
}
So, this runs... so the class is perfectly mutable but cannot be extended.
public class MyExtendedString extends MyString { .....
Not allowed.... However we can declare state to be final without the
class being final which would allow us to create useful extensions yet
still express immutability. That implementation would look some what
different than it does today but the advantages would be the ability to
express some of the complexities that you've mentioned along with many
others using a much simpler approach, proper encapsulation of the
abstraction that allows good use of polymorphisum. But allas, that
possibility has been taken away from us.
Regards,
Kirk
final class does not make internal state immutable, it only eliminates
the possibility to extend.Well, I can still use reflection to mutate state
> , and the code would have to defensively copy every
> string. Which goes right back to: Without enforcing immutability,
> strings suck.
>
> On Feb 23, 4:35 pm, kirk <[email protected]> wrote:
>
>> Reinier Zwitserloot wrote:
>>
>>> This 'you don't mother other developers' bullpucky needs to stop, now.
>>>
>> I'm sorry but historically this was a justification for making the class
>> final. I agree, it's a bogus argument. Having mutable Strings in
>> Smalltalk didn't make String un-usable just as having mutable Strings in
>> other langauges didn't make them un-usable either.
>>
>>
>>> *) knowing how the JVM works internally is not something your average
>>> programmer is supposed to need to comprehend, so you must assume they
>>> don't.
>>>
>> Too bad because that is a tool of our trade and not knowing how it works
>> is a handicap in my not so humble opinion (when it comes to this subject
>> but I digress)
>>
>> Regards,
>> Kirk
>>
>>
>>> On Feb 23, 2:44 pm, Alexander Snaps <[email protected]> wrote:
>>>
>>>> On Mon, Feb 23, 2009 at 8:29 AM, Peter Becker
>>>> <[email protected]>wrote:
>>>>
>>>>> kirk wrote:
>>>>>
>>>>>> Peter Becker wrote:
>>>>>>
>>>>>>> kirk wrote:
>>>>>>>
>>>>>>>> [email protected] wrote:
>>>>>>>>
>>>>>>>>> On Feb 17, 6:15 am, Alexander Snaps <[email protected]> wrote:
>>>>>>>>>
>>>>>>>>>> On Sun, Feb 15, 2009 at 7:13 PM, Reinier Zwitserloot <
>>>>>>>>>>
>>>>> [email protected]>wrote:
>>>>>
>>>>>>>>>>> I mark any immutable class final, because if it isn't, then you
>>>>>>>>>>>
>>>>> can't
>>>>>
>>>>>>>>>>> rely on its immutability (any subclass is assignment compatible and
>>>>>>>>>>>
>>>>> is
>>>>>
>>>>>>>>>>> not neccessarily immutable!).
>>>>>>>>>>>
>>>>>>>>>> While I tend to agree with marking "type" classes as final, I don't
>>>>>>>>>>
>>>>> believe
>>>>>
>>>>>>>>>> that a class being immutable is reason enough to mark it final.
>>>>>>>>>>
>>>>>>>>> If it's not final, it probably isn't immutable. Take java.io.File.
>>>>>>>>> Please.
>>>>>>>>>
>>>>>>>> Marking a class as final is a whole different ball game than marking a
>>>>>>>> variable as final. For example, marking String as final was a HUGE
>>>>>>>> mistake IMHO. It prevented people from making some very useful
>>>>>>>> extensions. It's also responsible for a lot of code bloat. I'm not
>>>>>>>> against making a class final. That said, to do so because of the need
>>>>>>>>
>>>>> to
>>>>>
>>>>>>>> mother other developers shouldn't be one of them.
>>>>>>>>
>>>>>>> If String wouldn't be final, then its immutability could not be
>>>>>>> guaranteed, which would mean you
>>>>>>>
>>>>>> final class doesn't mean the value is immutable, it means that the class
>>>>>> cannot be extended.
>>>>>>
>>>>> I'm aware of that, but if you don't put the "final" there even if you
>>>>> write a perfectly immutable class yourself, you can still not assume
>>>>> that all instances of it are immutable since subclasses might break that
>>>>> assumption. So if you want an immutable class, then you have to
>>>>>
>>>>> (a) make sure you write it immutable, and
>>>>> (b) make it final.
>>>>>
>>>> I think you only make it final to "mother other developers", as Kirk said.
>>>> And I don't see this as a good enough reason... Besides there's always ways
>>>> to break something if that is what you want. Sadly also if that's what you
>>>> don't want. Constraining people all the time for their "best" is a scary
>>>> thought to me, even in software development.
>>>> My point is, it's not because a class is not marked as final that all class
>>>> extending it will break its immutability either!
>>>>
>>>>> And that's how the String class is done. A proper language concept of
>>>>> immutability would be much nicer, but it's not what was done.
>>>>>
>>>>> Peter
>>>>>
>>>> --
>>>> Alexander Snaps
>>>> <[email protected]>http://www.jroller.com/page/greenhornhttp://www.linkedin.com/in/alexa...
>>>>
> >
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
