none
y java is not fully object oriented programming compare 2 .net RRS feed

All replies

  •  

    Why Java is Not Suitable for Object-Oriented

    Frameworks

    1. JAVA DOES NOT SUPPORT

    COVARIANT RETURN TYPES

    The Java type system doesn't support covariant return types

    (i.e., subclasses can't change the return type of an inherited

    method to a subtype). The lack of covariant return types has a

    significant impact on how developers use Java. This ranges from

    simple messages like accessors, through idioms like polymorphic

    copy, through design patterns like Factory Method, Manager or

    Singleton [1]. In effect, Java's type system introduces roadblocks

    that developers must code around. Sometimes they may get

    around with a type cast. Other times, to avoid downcasting, they

    may have to widen the API with methods that simply narrow the

    return type (e.g., getMySessionContext vs.

    getSessionContext). This makes applying the white-box and

    black-box reuse techniques specific to object-oriented frameworks

    cumbersome [2]. It also breaks layering, making developers aware

    of the objects at different levels of abstraction.

    2. JAVA'S STATIC TYPE CHECKING

    PROVIDES A FALSE SAFETY NET

    Java is intended for building robust, reliable, and secure

    software. One of the mechanisms used to achieve these goals is

    static type checking. We have studied how well this works on a

    large-scale.1 eBusiness project involving several object-oriented

    frameworks [3]. Java's static type checking catches mainly trivial

    mistakes that seasoned developers and unit tests would catch

    anyway, without guaranteeing the elimination of run time

    problems. Without covariant return types, many Java frameworks

    involve explicit casts from a framework generic type to an

    application-specific type (customization through class

    composition is typical in white-box frameworks [4]). The

    compiler doesn't check casts. At run time the Java virtual

    machine reports casting problems by throwing a

    ClassCastException and usually terminating the application.

    Catching these exceptions involves a significant amount of

    manual type checking. This cycle greatly reduces the value of

    simple compile time type checking.

    3. REMOTE EXCEPTION = COUPLING

    Well-crafted distributed systems exhibit low coupling

    between the subsystem and object design and the deployment

    packaging structure. Once developers start to learn how an

    application performs in a distributed environment, they fine-tune

    it through re-partitioning the functionality between the serverspace

    and the client-space. This requires the ability to relocate

    components around the client-server boundary seamlessly. Java

    supports distributed programming natively through RMI. Java's

    RMI RemoteException subclasses Exception and requires

    explicit catch statements. This violation of the Liskov

    Substitution Principle2 essentially introduces coupling between

    domain objects and their location. Refactoring components from

    server-space to client-space involves wrapping remote message

    calls in try-catch blocks, which translates into hard-coding the

    location within the code. In effect, it hinders developers' ability to

    experiment with “concretizing” object locations when fine-tuning

    distributed applications [5]. It also litters the code and makes

    maintenance harder.

    1 The project involves over 700 Java classes and almost 9,000

    methods.

    2 The Liskov Substitution Principle (LSP) states that modules

    using references to base types must be able to use references to

    derived types without knowing the difference.

    4. ADDITIONAL PROBLEMS

    4.1 Visible source code

    Java lets developers separate the source from the byte codes.

    Although the core JDK classes ship with source code, developers

    don't have to do so. Typically third party frameworks and libraries

    ship as class files without source. But not having framework

    source code hampers your project. You can't see how the

    framework works; you can't add hooks that the original

    developers never thought would be needed; you'll have a hard

    time finding bugs. In short, you have to hope that the framework

    developers thought of all the things that you might possibly want

    to do with it, or else you are groveling at their door. The

    increasing popularity of the Open Source model provides a clear

    sign that developers benefit from having access to the source

    code. Note that distributing source code doesn't hinder the

    business aspect; Smalltalkers have made money for over 20 years

    from applications shipped with source code.

    4.2 Deprecated is a comment instead of a

    reserved word

    As frameworks evolve, some of their components become

    obsolete. Java lets developers deprecate methods, classes, or

    interfaces. This allows for the phasing out of functionality in a

    controlled way, giving framework users adequate time to adapt

    their code to the new mechanisms. However, Java hides this

    important tag in a comment, thereby reducing its visibility. When

    looking at a class to work out how to use it, most developers look

    at the class and method definitions first. It would make more

    sense for “deprecated” to be a keyword and to live in the

    definition (e.g., public static deprecated void MyClass())

    rather than in the comment. This would make compiler parsing

    easier, and would increase the visibility of this useful function.

    5. SUMMARY

    We have sketched the impedance mismatch between objectoriented

    frameworks and the Java programming language. More

    specifically, we have described some of the problems we

    encountered on a large Java project involving several frameworks.

    Software developers walking this path will benefit from our

    discussion. They will understand the tension between objectoriented

    frameworks and Java, and will learn how we dealt with it.

    Friday, December 7, 2007 9:15 AM
  • hi,

     

    1.by shortly in JAVA  we have protected specifier which violates its property by using in it is non derived class.

    where as in .NET it is not the case. we can use protected members only in its class and its derived class.

    2. in JAVA : static methods can be called using object also .... but in .NET we can call the static methods only by class name.

    like this so on.........

     

     

     

    Saturday, December 15, 2007 8:19 AM
  • According to my experience, Java is the best of all.. Java is developing its own .Net framework which is coming soon.... and it is far much better than other .Net frameworks

     

    Sunday, December 16, 2007 8:37 PM

  • Hey man !! Can you precise what you said ! you meant j#.net or anyother thing !!
    Thursday, December 20, 2007 11:02 AM