WinFX newsgroup post

I posted Rahul's question on a Microsoft Longhorn newsgroup and got a response. First, I hope I framed the question right, and second, the answer is NOT from a Microsoft employee. I wasn't impressed with the response, but judge for yourself.


> Hi,
>
> I'm just curious about something... I could be totally wrong so please
> correct me if I am.
>
> How would having Java in Longhorn work? If Longhorn API's is managed,
> then Java's API's which are also managed, will have to hook into these,
> wouldn't they? Wouldn't this sort of be a situation of have two managed
> layers? A lot of GUI functionality is dependant on the underlying platform,
> so would they have to make calls through Longhorn's API's instead of
> directly accessing them?

The Java UI would either have to use standard windows UI's(which as I
understand it hook into Avalon at some lower level, maybe a GDI thunking
layer?) as they do now, meaning that current java UI toolkits should still
work properly, or they could provide new versions of the toolkits that wrap
the managed API. As a note, if you are using platform specific UI's, you
always have to call through that platforms API, its just a matter of which
API you use.

It is also not clear to me if or how AWT, for example, would work with
Avalon. Its possible that the api's provided by the class set are not
sufficently expressive for the target system, or are to far at odds to
easily come to terms. Such things will remain to be scene as Longhorn
progresses and the various communities start exploring its capabilities.

> Also what about (native) C++? For ex. file streams... Would these need to go
> through the managed API's? If yes, wouldn't that cause some performance
> problems?

Not of any consequence. Any call overhead into the managed code should be
virtually undetectable when you consider the fact that file streams are disk
bound, not cpu bound. The slowest managed code is generally many times
faster than the disk.

> Thanks.