j#.not


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 3 of 3

Thread: j#.not

  1. #1
    Brad O'Hearne Guest

    j#.not


    As a developer who started professionally in the Microsoft world, and using
    J++ and COM/COM+ and shipped a commercial product during the time when MS
    basically dumped Java, and am now an experienced Java developer, I have some
    direct experience in the evolution of Java in the MS world.

    First off, it should probably be outright stated that J# is not a destination...it
    is a bridge. Bringing Java developers to J# is not the intended end of the
    road -- C# is. J# is nothing but the "bait" in a "bait and switch". This
    is Java vs. C#, or more appropriately, MS's new angle on owning the Java
    market that they couldn't own by bastardizing the Java platform specifications.
    This brings me to my next point.

    In his article, Russel Jones writes:
    "Sun has, for years, gone out of its way to ensure that Java doesn't interoperate
    with COM—in fact they went to court to enforce that isolation. Years later,
    Java still doesn't interoperate with COM. By following Microsoft's lead,
    Sun is also attempting to ensure that "You can check in, but you can never
    leave."

    This is patently untrue. There is nothing the Sun has done to prevent interoperation
    with COM, or for that matter, other languages, as they have provided the
    Java Native Interface (JNI) as a bridge to other languages. And for those
    that want to try to classify JNI as some fringe API not often used, they
    might want to consider the fact that large parts of all JDK's direct from
    Sun rely heavily on this API. In addition, MS could have developed a COM-Java
    API using JNI day one, but they didn't. In fact, until just recently, SQL
    Server was about the only database that didn't have a vendor-developed pure
    Java JDBC driver for it, which is an obvious display of the desire to integrate
    with Java. In addition, it is absurd to think that Sun would dump development
    effort into integrating a non-Java technology the competed with EJB (and
    is arguably quite inferior to it as well) -- this would naturally be the
    responsibility of the vendor of COM (MS), who apparently had no interest
    in doing so (actually, the funny thing is that they already did this in the
    form of COM-wrappers in J++, but rather than extend this technology to the
    dev community in the form of an API, they just dumped J++ when the Sun-MS
    lawsuit emerged -- I know about that one -- my dev group in 1998 had to do
    a complete rewrite of our product in C++ one month after shipping our GA
    code due to MS dropping Java-COM support).

    But the most outlandish claim from Jones is that Sun "went to court to enforce
    that isolation." Nothing could be more untrue. Sun's quarrel with MS was
    based on the fact the MS tried to violate the Java specification by injecting
    its own proprietary changes, and thereby defeating one of the primary (if
    not the primary) tenets of the spec, which was platform portability. Java's
    accommodation of multiple platforms is a testament to having all OS communities
    embrace the product -- it is MS that seeks isolation of Java on its platform
    of Windows only. This is clearly evident in MS's latest move of "Java apps
    that will run only in .NET". This is another attempt to screw with the Java
    spec.

    The question of whether developer's would care for a version of Java that
    worked only on .NET is moot -- read the Java specs -- such a language isn't
    Java.

    Again, another point of Jones:
    "Sun ignores its developers' need to write robust native Java desktop applications".

    Not so -- heard of Swing? For all the trashing it gets, the number one development
    IDE for Java several years running just happens to be a pure Swing app (JBuilder),
    and I personally am part of a team developing our mission-critical GUI in
    pure Swing. While Swing has understandable overhead, it is more than sufficient
    for a rich-featured GUI, and better yet, it is portable.

    And finally, from Jones:
    "Today, developers are faced with an unpalatable choice: One language for
    all platforms or one platform for all languages."

    This is a gross over-simplification of the reality. The real issue includes
    these:

    1)Implementation vs. specification.
    2) Single vendor vs. multi-vendor.
    3) Single choice vs. Best-of-breed.

    These are huge issues that Jones completely overlooks. The implications
    of these:
    1) MS delivers full proprietary closed implementation of its products, while
    Sun delivers specifications which must be followed for compliance, but can
    be flexible based on implementation needs.
    2) The MS way puts all your eggs in one basket...whereas there are vendor
    alternatives using Java.
    3) Because of 1), there are no choices the MS way, but you are given a best-of-breed
    choice using Java.

    The two communities are entirely different. Everyone needs to wake up and
    smell the coffee. J# is a marketing stunt, and a migration path to C#.



  2. #2
    Mark Hurd Guest

    Re: j#.not

    "Brad O'Hearne" <brado@neurofire.com> wrote in message
    news:3bd126a0$1@news.devx.com...
    ><snip>
    >
    > The question of whether developer's would care for a version of Java that
    > worked only on .NET is moot -- read the Java specs -- such a language isn't
    > Java.


    This is what I've always seen as silly. There is no reason why a language has
    to be tied to an implementation (except when you've signed a contract that
    says you'll do just that).

    That an entity that designed a language also had a goal to design an
    implementation spec that makes it straightforward to target any system is a
    good idea, but the language is a good OO language in its own right. (Is there
    anything about the *language* that was clearly chosen due to the platform
    indepence goal?)

    The language and its virtual machine (computer science term) is separate from
    an implementation.

    If I produce an open source C runtime library that is structured so that it is
    very clear that if a specific implementation passes a well-defined suite of
    tests then the implementation will produce the same functionality, I then have
    achieved the same goal, except the language is not OO.

    I might add that part of the problem is the user interface look and feel that
    must be the lowest common denominator. If there is an X widget and a Windows
    control that don't have equivalent objects in another windowing system, then
    should they be ruled out of Java programs?

    Just like most multi-platform projects, the answer will be to conditionally
    compile for each platform. And if your going to allow this for GUI
    differences, why not allow it for other differences?

    This is where the obvious alterative of not allowing any differences fits in,
    but it is a design choice, not something that is tied to the language.

    In other words, platform independence implies Java (or extra work and worry)
    but Java should not necessarily imply platform independence if that is not a
    goal of your project.

    However I am confused. I thought C# existed because Java was not available.
    How can MS get past the contract they were held to in the previous Sun vs. MS
    court case?

    ( Also, if J# was coming, could it have been the bridge between C++ and
    VB.Net? Then VB.Net could have had all of the features C# has got that VB.Net
    ought to have too... :-) )

    Regards,
    Mark Hurd, B.Sc.(Ma.) (Hons.)



  3. #3
    Aaron Sevivas Guest

    Re: j#.not


    I agree with some of what u said but :

    >Again, another point of Jones:
    >"Sun ignores its developers' need to write robust native Java desktop applications".
    >
    >Not so -- heard of Swing? For all the trashing it gets, the number one

    development
    >IDE for Java several years running just happens to be a pure Swing app (JBuilder)


    Jbuilder from, I believe 4.0 and up is java swing, earlier versions were
    c++. And if you use it, it works fine, but u can't compare it to Ms' Visual
    Studio ide as far as performance. Many believe the performance of Jbuilder
    is great because they have become accustomed to using it (I have been using
    it every day, 9-5 for the past 6 months and i agree, the performance is acceptable).
    but if you do a side by side comparison between JBuilder and MS VS, JBuilder
    hasn't a chance.

    >And finally, from Jones:
    >"Today, developers are faced with an unpalatable choice: One language for
    >all platforms or one platform for all languages."
    >
    >This is a gross over-simplification of the reality. The real issue includes
    >these:
    >
    >1)Implementation vs. specification.
    >2) Single vendor vs. multi-vendor.
    >3) Single choice vs. Best-of-breed.
    >



    >These are huge issues that Jones completely overlooks. The implications
    >of these:
    >1) MS delivers full proprietary closed implementation of its products, >while
    >Sun delivers specifications which must be followed for compliance, but can
    >be flexible based on implementation needs.


    OR.. Microsoft black-boxes its implementations, assumes responsibility for
    source code and allows the developer to worry about business needs whereas
    Sun allows individual coders to break working implementations by creating
    white-box dependent inheritence schemes with distributed classes.

    >2) The MS way puts all your eggs in one basket...whereas there are vendor
    >alternatives using Java.


    I agree that as far as app servers, MS gives us very little choice, but the
    supported languages the CLR supports are in the hundreds. The CLR is MS but
    you can choose from hundreds of vendors for your language/ide s..

    >3) Because of 1), there are no choices the MS way, but you are given a best-of-breed
    >choice using Java.


    Client/server using java.. Client is written in ? Server is written in ?
    Unless your using your own cooked up protocol or SOAP, its Java. No choice
    there.

    >J# is a marketing stunt, and a migration path to C#.


    true

    my $.02

    ~aaron


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center