Hi, >1) If you are deploying Java on the server you are protected by so many >layers, code obfuscation is not critical If you want to distribute your app without people getting access to the code itself, being on client or server is not relevant. Whatever the reason for wanting to do so. > 2) If you are deploying Java Applets for enterprise applications, you > are nuts. They are inherently insecure and Java applets have a long > history of critical problems. So have cookies and javascript based web applications. Yet cookies are used everywhere for anything/everything and "ajax" is the new big boy in town. It is not because something is insecure that people don't use it in the real world, not the perfect secure one. You would be amazed of how many times I heard "it's useless to check again the data on the [php|java|asp|perl] side, we already did it in JS" or "why add a java middle-tier server side, we can obfuscate the jar file and have the client PC talk directly to the database" (yeah sure, I'll make a public, unencrypted, access for you guys). >From a security *threat* point of view, I agree that we could/should more of these issues. > > With the continuous move towards bytecode type of languages (with java > > and .NET being the prime examples) Same goes with PHP BTW. JG
