Berkeley CSUA MOTD:2000:November:24 Friday <Thursday, Saturday>
Berkeley CSUA MOTD
 
WIKI | FAQ | Tech FAQ
http://csua.com/feed/
2000/11/24-25 [Recreation/Food] UID:19905 Activity:high
11/23   What is this? Turkey makes all the sysadmins with bad attitudes
        come out of the woodwork? Good grief! I thought turkey was
        supposed to make you feel goooood.    - veggie
        \_ Omnivores would like you to believe that. - another veggie
        \_ Don't bring your ridiculous veggy politics into this.  There's no
           more grumpiness now than on any other motd.  -- kills and eats veggies
2000/11/24-28 [Computer/SW/Languages/Java] UID:19906 Activity:high
11/23   Ok, we know that to implement OOP methods you have these nifty
        virtual function tables which are assigned and thus  have supposedly
        independent namespaces.  How are protected variables implemented in
        Java or C+?
        \_ same was public members are implemented. protection comes in
           the early stages of compilation. by the time you get to code
           generation, that information is not relevant.
           \_ not strictly true for Java (access control is verified by JVM).
              But generally right -- access control is a compile-time issue.
              \_ typechecking by the JVM can be subverted by writing your
                 own classloader in bytecode; i'm just trying to figure out
                 why the "checks" don't work in java.
                 \_ Ok, I think I understand now.  "protected" in Java is
                    slightly differrent then protected in C++ -- it also
                    allows access by the classes from the same package
                    (like default access).  Why?  I don't know -- ask th
                    people who wrote the JLS.  But it makes for an annoying
                    interview question. ;)
                    \_ One that you'd get wrong.  You describe the default
                       access control, which does not have a keyword.
                       \_ Default access control in java is the same as that
                          specified by the 'protected' keyword.
                    As for runtime control -- it's disabled by default for
                    local classes, you need to run java -verify to explicitly
                    enable it.  I don't think writing your own classloader
                    will help subvert verification (otherwise it would be a
                    huge hole in the security model).
                    \_ Dude.  Neither C++ nor java have true 'security.'  In
                                correctly (use doPrivileged())
                       C++ you get around it by casting, in java you get around
                       it by using reflection.  At any rate, I haven't seen a
                       language that enforces variable privacy.
                        \_ Uh, reflection actually DOES enforce variable
                           privacy policy in 1.1 and I think in 1.2, which
                           is actually a royal PITA since you want that
                           interface to build development tools.
                        \_ Not in Java 1.2 and higher if you write your code
                                correctly (use doPrivileged() together with
                                a security policy)
Berkeley CSUA MOTD:2000:November:24 Friday <Thursday, Saturday>