- 3,715,709 Users
- 2,242,839 Discussions
- 7,845,504 Comments
Forum Stats
Discussions
Categories
- 17 Data
- 362.2K Big Data Appliance
- 7 Data Science
- 1.6K Databases
- 467 General Database Discussions
- 3.7K Java and JavaScript in the Database
- 22 Multilingual Engine
- 487 MySQL Community Space
- 3 NoSQL Database
- 7.6K Oracle Database Express Edition (XE)
- 2.8K ORDS, SODA & JSON in the Database
- 416 SQLcl
- 42 SQL Developer Data Modeler
- 184.9K SQL & PL/SQL
- 21K SQL Developer
- 1.9K Development
- 3 Developer Projects
- 32 Programming Languages
- 135.1K Development Tools
- 8 DevOps
- 3K QA/Testing
- 248 Java
- 5 Java Learning Subscription
- 10 Database Connectivity
- 66 Java Community Process
- 1 Java 25
- 9 Java APIs
- 141.1K Java Development Tools
- 6 Java EE (Java Enterprise Edition)
- 153K Java Essentials
- 135 Java 8 Questions
- 86.2K Java Programming
- 270 Java Lambda MOOC
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 10 Java SE
- 13.8K Java Security
- 3 Java User Groups
- 22 JavaScript - Nashorn
- 18 Programs
- 125 LiveLabs
- 30 Workshops
- 9 Software
- 3 Berkeley DB Family
- 3.5K JHeadstart
- 5.7K Other Languages
- 2.3K Chinese
- 3 Deutsche Oracle Community
- 10 Español
- 1.9K Japanese
- 2 Portuguese
what securing code is hard!!

Hi
im a new project manager supervising the development of a javafx desktop application, iv made the choice considering the java xplateforme benefits especially on low dev costs .
i discovered that securing the code is a very ( and very) hard task. according to my team and my googling research result, its impossible to deny access to your code , even obfuscating the jar.
IS IT POSSIBLE ???? I CANT BELIEVE that ! if real, what meanful the speaking on security on java is ? hope find a response to that .. in instance thanks a lot
Answers
-
Aykut,
Since Java runs on the JIT (just in time compiler) your code has to be readable and since it translates down to byte code, it has to be read by the JVM at execution time. So you are left to work within that framework. You can make it more difficult to steel your code, but you are talking about an open system you have chosen to use in development, it rubs against the basic philosophy of Java.
So you enter the what I call they why Bother Zone of application development. Obfuscate or not to obfuscate, that is the question. I did an exercise purely for my own curiosity sake and reverse engineered an obfuscated project. It took more time, but was very doable. So you can make it harder to get to an understanding of your source by reverse engineering. Egh.
You can get a program to give you an EXE out and lose all the niceties of being able to run anywhere there is a supporting JVM. Again I say: egh.
Another approach is to do Enterprise level Java solution and host your project on the web, so your client does not get you system, just some HTML interfacing produced by your web service. Well... egh.
Security it a billion dollar a year industry and hiding your code behind bulletproof inscriptions and locks can be far more expensive than the original development. So Open Source has sprung up and is alive and well. Use it, abuse it, make it, break it... pay for support and make us rich.
I choose the latter where the client pays for support: installation and yearly support licensing and etc.