The Artima Developer Community
Sponsored Link

Weblogs Forum
"hi there".equals("cheers !") == true

24 replies on 2 pages. Most recent reply: May 27, 2003 4:01 PM by Vlad Roubtsov

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 24 replies on 2 pages [ « | 1 2 ]
Harikrishnan Suresh

Posts: 1
Nickname: itzsuresh
Registered: May, 2003

Re: "hi there".equals("cheers !") == true Posted: May 24, 2003 10:47 AM
Reply to this message Reply
Advertisement
Hi Heinz,
Welcome to the Artima Weblogs. As usual another brilliant article from you.


How then do you think can the String class be made really immutable? ( i cant go abt every class that i use, to see if that uses reflection to modify my class ;) )

Regards,
Suresh

Heinz Kabutz

Posts: 46
Nickname: drbean
Registered: May, 2003

Re: "hi there".equals("cheers !") == true Posted: May 24, 2003 11:05 AM
Reply to this message Reply
> Hi Heinz,
> Welcome to the Artima Weblogs. As usual another
> her brilliant article from you.
>
>
> How then do you think can the String class be
> be made really immutable? ( i cant go abt every
> class that i use, to see if that uses reflection to
> modify my class ;) )
>
> Regards,
> Suresh

Hi Suresh,

Thanks for the welcome :-)

as far as I can tell, it is not possible to make String
truly immutable, without changing the way that arrays work.

Heinz

Hristo Stoyanov

Posts: 5
Nickname: hristo
Registered: May, 2003

Re: "hi there".equals("cheers !") == true Posted: May 24, 2003 8:43 PM
Reply to this message Reply
Lyndon -,
I agree and I know that self-modifying code is used increasingly, sometimes without regard to the consequences.
Then all bets are off. And in this case - it is not Sun's fault.

There are several degrees of "code alternations",
that allow you to change the intent of some initial API:

1. Brutal breaching of the Java language security
thru run-time reflection (like in the example)
2. Use "bytecode weaving" over already compiled code (as in some AOP and class tranformation frameworks)
3. Decompile the code back to Java source, modify it,
compile again, preserve the same JAR name.
4. Re-write the application totally , just keep the same
name of the executable.
5. Invent a new language (let's say C#) and convince everyone that it offers the rougly same APIs as Java as well as the same security/code protection features ;-)



Hristo

Hristo Stoyanov

Posts: 5
Nickname: hristo
Registered: May, 2003

Re: "hi there".equals("cheers !") == true Posted: May 24, 2003 8:50 PM
Reply to this message Reply
Thanks Vlad-,
Thanks for the pointers!
Until recently I was unaware about the memory costs of multi-dimensional arrays. I recently found out about it in
Dr Heinz newslwtter.

Memory conservation is, indeed, a big problem for in-memory object servers and huge caches. You may have heard about Prevayler (http://www.prevayler.org). Someone on the mail list there suggested the use of Unicode-compatible compression, which preservers the comparability of the original strings, as a means to conserve memory.

Hristo

Chris Dailey

Posts: 56
Nickname: mouse
Registered: Dec, 2002

Re: It's insecure code! Posted: May 25, 2003 8:03 PM
Reply to this message Reply
So why is there a setAccessible(boolean) method on Field? Oh, I see it is required for serialization and other persistence mechanisms to work.

I suppose if you want to feel safer, you can try this:
> java -Djava.security.manager MindWarp
Exception in thread "main" java.lang.ExceptionInInitializerError
at MindWarp.<clinit>(MindWarp.java:8)

Heinz Kabutz

Posts: 46
Nickname: drbean
Registered: May, 2003

Re: It's insecure code! Posted: May 26, 2003 2:07 AM
Reply to this message Reply
> So why is there a setAccessible(boolean)
> method on Field? Oh, I see it is required
> for serialization and other persistence mechanisms to
> work.
>
> I suppose if you want to feel safer, you can try
> this:
> java -Djava.security.manager MindWarp
> Exception in thread "main"
> java.lang.ExceptionInInitializerError
> at MindWarp.<clinit>(MindWarp.java:8)


Sure, you'll feel safe, but there will be a whole lot of other things you won't be able to do. What is needed is a proper security policy file that lists EXACTLY what you are and are not allowed to do.

I am yet to discover a company that runs their applications with security managers.

Heinz

Vlad Roubtsov

Posts: 20
Nickname: vladr
Registered: May, 2003

Re: It's insecure code! Posted: May 27, 2003 3:38 PM
Reply to this message Reply
> So why is there a setAccessible(boolean)
> method on Field? Oh, I see it is required
> for serialization and other persistence mechanisms to
> work.

Java serialization does not need to rely on setAccessible() anymore post Java 1.3. It can't anyway (final fields are a problem). Current J2SE platforms use native code for serialization.

Vlad Roubtsov

Posts: 20
Nickname: vladr
Registered: May, 2003

Re: It's insecure code! Posted: May 27, 2003 3:43 PM
Reply to this message Reply
> Sure, you'll feel safe, but there will be a whole lot of
> other things you won't be able to do. What is needed is a
> proper security policy file that lists EXACTLY what you
> are and are not allowed to do.
>
> I am yet to discover a company that runs their
> applications with security managers.
>
> Heinz

J2EE application servers rely on security managers to enforce J2EE coding restrictions.

Furthermore, establishing a correct policy file is easier than it seems using tools like Stu Halloway's permission sniffer: http://staff.develop.com/halloway/code/PermissionSniffer.html

A tool like that is not even particularly hard to write yourself. Create a custom SecurityManager that permits everything your app needs during normal operation and log all permissions requested. Dump them in a policy format at the end.

Heinz Kabutz

Posts: 46
Nickname: drbean
Registered: May, 2003

Re: It's insecure code! Posted: May 27, 2003 3:50 PM
Reply to this message Reply
> > Sure, you'll feel safe, but there will be a whole lot
> of
> > other things you won't be able to do. What is needed is
> a
> > proper security policy file that lists EXACTLY what you
> > are and are not allowed to do.
> >
> > I am yet to discover a company that runs their
> > applications with security managers.
> >
> > Heinz
>
> J2EE application servers rely on security managers to
> enforce J2EE coding restrictions.
>
> Furthermore, establishing a correct policy file is easier
> than it seems using tools like Stu Halloway's permission
> sniffer:
> http://staff.develop.com/halloway/code/PermissionSniffer.ht
> l
>
> A tool like that is not even particularly hard to write
> yourself. Create a custom SecurityManager that permits
> everything your app needs during normal operation and log
> all permissions requested. Dump them in a policy format at
> the end.

Sure, it is not hard to write, but if you look at standard Java applications (i.e. standalone, not running on an application server), I bet that very few developers would spend the time writing them correctly. Or maybe I have just not seen the right types of projects?

So, let's not worry whether this is insecure or not. It is plain stoooooopid to do something like this, and I am almost 100% sure that you won't find such code anywhere in a real system. It is just amusing to see that two different constant Strings can be made to equal each other :-)

Or maybe we could tackle the big problem of i18n like this? *evil grin*

Vlad Roubtsov

Posts: 20
Nickname: vladr
Registered: May, 2003

Re: "hi there".equals("cheers !") == true Posted: May 27, 2003 4:01 PM
Reply to this message Reply
> Memory conservation is, indeed, a big problem for
> in-memory object servers and huge caches. You may have
> heard about Prevayler (http://www.prevayler.org). Someone
> on the mail list there suggested the use of
> Unicode-compatible compression, which preservers the
> comparability of the original strings, as a means to
> conserve memory.
>
> Hristo

Yep, I am familiar with the idea. When I wrote the data size article I omitted a simple trick that works well with long/mostly-ASCII strings by keeping them inside java.rmi.MarshalledObjects in memory.

A better idea was suggested by a reader: use the SCSU Unicode compression scheme in IBM's ICU4J kit (http://www-124.ibm.com/icu4j/doc/com/ibm/icu/text/UnicodeCompressor.html). I did some informal testing and SCSU was 2-4x times faster than MarshalledObject serialization. It also works well for Strings that contain block of chars in other languages, not just ASCII blocks.

Flat View: This topic has 24 replies on 2 pages [ « | 1  2 ]
Topic: Refactoring To Aspects Previous Topic   Next Topic Topic: Half Sisters


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us