This discussion is archived
8 Replies Latest reply: Oct 11, 2012 9:50 AM by 939520 RSS

Developing an common methods

SRAVZ Newbie
Currently Being Moderated
All,


I want to develop a java utility(common methods) and make sure the source is secured, what are the best possible ways to do it. I donot want share the source code neither want some one to decompile it.

Please let me know
1. How do i structure the source
2. How do leverage security
3. Any recommendation on best practices

Thanks in advance.

Thanks
Sravz
  • 1. Re: Developing an common methods
    939520 Explorer
    Currently Being Moderated
    This may help:
    http://stackoverflow.com/questions/49379/how-to-lock-compiled-java-classes-to-prevent-decompilation

    I suggest you don't bother doing so though. Whatever functionality your code provides can probably be either easily reversed engineered or more likely code that performs the same functionality can be found on-line for free. Also, like many applications out there, your code probably sucks and is not worth stealing ;) What you should really protect is access to your database as it contains sensitive data such as social security numbers. The best way of doing so is to have a web application where the Java code runs back on the server with no business code or passwords on the client machine. Any data coming from the client should be validated and checked for hacker corruption (sql injection attacks, etc).
  • 2. Re: Developing an common methods
    DrClap Expert
    Currently Being Moderated
    You have to first ask yourself why you don't want anybody else to see your source code. Specifically: what costs arise if somebody sees it, and what benefits accrue to you if nobody can see it.
  • 3. Re: Developing an common methods
    rp0428 Guru
    Currently Being Moderated
    >
    I donot want share the source code neither want some one to decompile it.
    >
    Then it may come as a shock to you that the JDK includes a disassempler as part of the package.
    >
    E:\>javap -help
    Usage: javap <options> <classes>...

    where options include:
    -c Disassemble the code
    -classpath <pathlist> Specify where to find user class files
    -extdirs <dirs> Override location of installed extensions
    -help Print this usage message
    -J<flag> Pass <flag> directly to the runtime system
    -l Print line number and local variable tables
    -public Show only public classes and members
    -protected Show protected/public classes and members
    -package Show package/protected/public classes
    and members (default)
    -private Show all classes and members
    -s Print internal type signatures
    -bootclasspath <pathlist> Override location of class files loaded
    by the bootstrap class loader
    -verbose Print stack size, number of locals and args for methods
    If verifying, print reasons for failure


    E:\>
    >
    Does that tell you anything?
  • 4. Re: Developing an common methods
    aksarben Journeyer
    Currently Being Moderated
    As the other replies indicate, securing the code is usually unrealistic. The only way to prevent reverse engineering to is to make the code inaccessible to users (for instance, as a server app). Other than that, there's no practical way to do it. If a user has access to code, he can figure it out.

    This problem is as old as the hills, & basically insoluble. If you're worried about losing money in a commercial app, find some other way to make money (such as support).
  • 5. Re: Developing an common methods
    gimbal2 Guru
    Currently Being Moderated
    aksarben wrote:
    This problem is as old as the hills, & basically insoluble. If you're worried about losing money in a commercial app, find some other way to make money (such as support).
    You mean to sell support on the software, not to let go of development and become a support employee as I wrongly interpreted the first time I read that ;)

    Tis true; the market is learning that you can earn more by giving away the stuff for free first. Free to play games for example, but also Java itself is a good example. Its free, but if you want any kind of Q&A and long-term support prepare to pay for it.
  • 6. Re: Developing an common methods
    SRAVZ Newbie
    Currently Being Moderated
    Ok Thanks for the comments

    I think i would not worry about security now, if i want write common methods how do i proceed .i.e. for example do i have to create an interface(may b abstarct) and extend a class which has the implementing details or do a class which has 1000 methods in it.

    Whats the recommendation, i understand my question is at high level but request you to guide me.

    Thanks
  • 7. Re: Developing an common methods
    TPD-Opitz-Consulting-com Expert
    Currently Being Moderated
    SRAVZ wrote:
    if i want write common methods how do i proceed .i.e. for example do i have to create an interface(may b abstarct) and extend a class which has the implementing details
    Looks like you should learn what Interfaces ans (abstract) classes are good for.
    Also it would be a good idea to learn about design pattern, because a "common" library should provide support for those...
    or do a class which has 1000 methods in it.
    Definitly not!
    The common line in OOP is: classes and methods should be as short as possible.

    Here are some points that come to my mind:
    <ul>
    <li>Provide a small interface (number public classes and methods) to your users. </li>
    <li>Take (a lot of) time to find proper names before your first release.</li>
    <li>Take eaven more time for separation of concerns (what does an object do)</li>
    <li>provide Factories for object creation if objects need complex configuration.</li>
    <li>If your clients have to pass parameters to your Methods provide interfaces they must implement or Enumerations (for fixed values).</li>
    <li>for complex interfaces (more than one method) provide (abstract) default implementations.</li>
    <li>provide a (JUnit-)Test suite to proove proper functionality of your code.</li>
    <li>publish your lib in a maven or ivy repository along with a dependency description so that your lib and its dependencies can be easily integrated.</li>
    </ul>
    There is a lot more to consider. Hopefully other forum members will add important points I missed...

    bye
    TPD
  • 8. Re: Developing an common methods
    939520 Explorer
    Currently Being Moderated
    Here are some additional ideas:
    I suggest you provide javadoc at the top of each class/interface that is exposed to the user on what service the class provides. Also, javadoc for each function on what it does (not how it does it), possibly what it returns, and what input arguments its expecting. Remember the user probably can't look at your source code of the function to determine what it does. He's relying on your javadocs. I suggest you let the customer know that all function arguments are assumed not to allow null values unless otherwise specified in the function's javadoc. Lastly, you may consider adding what checked exceptions are thown and why in the function's javadoc if the function can throw them. Don't add javadoc describing unchecked exceptions (often thrown if the user violates your javadoc's contract).

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points