This is the mail archive of the kawa@sourceware.org mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [path] refactored ReplPane.enter() / cleanups


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/04/11 19:15, Per Bothner wrote:
> The most important thing missing is a ChangeLog entry.

Noted.

> The @Eoverride annotations for inner classes seems indented wrong - it is
> certainly different from what emacs (23.2.1) does.

Sorry, I don't like to blame my tools, but I just accepted what NetBeans
did. Based on your previous comments, I'll drop back to Emacs for editing.

> The comment "implement a volatile variable that keeps track of when the
> thread should stop" doesn't really seem like a solution: What if you're
> executing an infinite loop?  Generating a test of a volatile variable
> at each "sequence point" (e.g. before looping back) seems like an
> unacceptable performance killer.

Clearly I hadn't thought too much about the performance ramifications of
this. The only other technique I currently know of to "safely" stop a
thread is to use the threads interrupt flag as a stop flag, but then I
suppose you'd need a new method to check if that flag is set, which
would cause a performance hit. Threading is new to me, I was just
looking for a way to avoid using this deprecated method. I don't
understand the comment that Thread.destroy() isn't implemented, it is,
but that's also deprecated! Ugh.

> I don't think changing 'kind == ReplPane.ViewableElementName' to
> 'kind.equals(ReplPane.ViewableElementName)' is needed unless Swing
> behind-the-scenes makes a copy of the incoming String.  I guess in
> theory Swing might do that (perhaps internally Swing might use UTF-8
> byte arrays - like javac does), and the code is not performance-critical,
> so it may be reasonable to use equals.

Ah, I might have made a mistake here, I was worried that this condition
might not have been what was intended, since I thought the object
references might have been different, even though the contents of the
strings were the same.

Please may someone explain why this is done,

public static final String ViewableElementName = "Viewable";
public static final Object ViewableAttribute =
    new String(ViewableElementName);

Why bother with the String constructor?

Thanks for the feedback,

Charles.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJNpLd2AAoJEG9M6fiX7bE4OrEIAITP8mnb3xC16NHdbjMJdwru
rM51T5SjH/iaghR5DsunC4KeHw1K6klYFEQ/LiimLmUa9Mxla+krAyJaMQZkqghi
If9B4PGzN/8m0oNGg1zb5eFpVGNbzHLaj5sPE4xMy38IJCPO9ZH5i+YYX/iCcG14
daicWB1seSQQ8/PrVakQtZHI0ppV3CEQgu31Y/CK69YJGSd+2HQlu9QPGTh15hx+
UBfXKJe6LeFVQJvE46FNAdZtrOwwnY9W6fSIAU5gDFiKyx6cZHqE7hoZBX7hcEWm
4XsF+YHPk4WY0Yj0xj20m0CVXKxwXPUmINJEQ5LWo17YLQfE7sBsO3DNM01Uc80=
=uBgC
-----END PGP SIGNATURE-----


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]