«

On 22-10-2010 00:26, ClassCastException wrote:
> On Thu, 21 Oct 2010 22:23:59 -0400, Arne Vajhøj wrote:
>> On 21-10-2010 21:40, Steve Sobol wrote:
>>> In article<i9q0bo$u2r$>, says...
>>>> MS essentially killed off their own Java implementation as well, and
>>> no one
>>>> noticed.
>>>
>>> That was different. Microsoft Java was a bastardized version of Java
>>> based on a 1.1 JVM with some M$-specific extensions.
>>
>> Not only extensions.
>>
>> Also a few things removed that MS did not want there.
>>
>> The latter has a pretty bad impact on portability.
>
> So do non-standard extensions: developers use them (sometimes
> unwittingly) and then their code isn't portable to the whole rest of the
> world.

True.

But that happens all the time both in Java (and other languages).

A standard does not prevent non-portable code. A standard makes
it possible to write portable code.

You can avoid using non standard extensions and other ways of
writing non-portable code.

You can not do anything to protect against somebody not implementing
the full standard.

Arne

On 22-10-2010 03:48, BGB / cr88192 wrote:
> JNI and JNA leave a bit to be desired...
> having to use pre-existing classes or interfaces to interface Java with
> anything else is... lame...
>
> these are not unfixable problems, but thus far the major VM's have not done
> much to improve on them.
>
> even CNI (like GCJ) would be an improvement (just better would be not having
> to use GCJ to use it...).
> admittedly, this front is a little awkward...
>
> but, I am left to wonder sometimes if the poor interface mechanisms are
> maybe deliberate...

It has certainly had the effect that the usage of JNI is rare.

> OTOH, MS gives us P/Invoke and, better yet, C++/CLI. P/Invoke then provides
> a slightly less awkward way to glue the languages, and C++/CLI allows, more
> so, the ability to write code which sits right on the border...
>
> now, if this would be done without depending on MS's technology or dealing
> with the relatively poorer quality of the existing OSS VM's (and the
> apparent issue that C++/CLI is currently specific to MS's VM), this would be
> better.

The MS C++ ability to generate mixed mode code is a very
sophisticated piece of technology.

Arne

"Arne Vajhøj" <> wrote in message
news:4cc2160b$0$23763$...
> On 22-10-2010 03:48, BGB / cr88192 wrote:
>> JNI and JNA leave a bit to be desired...
>> having to use pre-existing classes or interfaces to interface Java with
>> anything else is... lame...
>>
>> these are not unfixable problems, but thus far the major VM's have not
>> done
>> much to improve on them.
>>
>> even CNI (like GCJ) would be an improvement (just better would be not
>> having
>> to use GCJ to use it...).
>> admittedly, this front is a little awkward...
>>
>> but, I am left to wonder sometimes if the poor interface mechanisms are
>> maybe deliberate...
>
> It has certainly had the effect that the usage of JNI is rare.
>

yes.

Sun devises nearly the worst possible way to interface between C and Java
and standardizes on it as a covert attempt to prevent people from plugging
together C and Java code except in case of dire emergency...

about the only real way it really could have been worse was with a
"GetProcAddress" clone, lots of function-pointer casting, and having to use
calls to submit methods to the VM. now, this could have been worse...

granted, using calls to submit API functions/methods is typical in many
simple interpreters.



>> OTOH, MS gives us P/Invoke and, better yet, C++/CLI. P/Invoke then
>> provides
>> a slightly less awkward way to glue the languages, and C++/CLI allows,
>> more
>> so, the ability to write code which sits right on the border...
>>
>> now, if this would be done without depending on MS's technology or
>> dealing
>> with the relatively poorer quality of the existing OSS VM's (and the
>> apparent issue that C++/CLI is currently specific to MS's VM), this would
>> be
>> better.
>
> The MS C++ ability to generate mixed mode code is a very
> sophisticated piece of technology.
>

granted, but little says that it is outside the reach of a corporation with
a pile of developers and money...


FFS I have devised some vaguely similar pieces of technology (actually, more
mixing compiler and interpreter technology, and using dynamic code
generation to glue stuff together, but close enough, directly mixing
bytecode and native code is the next logical step), and I am a lone hobbyist
with neither endless supplies of time nor money. Sun could have probably
done similar much more easily...

after all, they did get the JVM itself working, and looking at it, improving
the FFI would not have likely been anywhere as near a complicated of a task
if they wanted to do so.

I am left to suspect that, more likely, they were intentionally working to
keep C and Java separate as a means of promoting their particular vision.

granted, not everyone has exactly the same vision, and some would probably
want to see this wall being lessened.


but, as is the usual rule of everything: if one wants something done a
certain way, inevitably they will need to do it themselves.

On Fri, 22 Oct 2010 18:50:47 -0400, Arne Vajhøj wrote:

> On 22-10-2010 00:26, ClassCastException wrote:
>> On Thu, 21 Oct 2010 22:23:59 -0400, Arne Vajhøj wrote:
>>> On 21-10-2010 21:40, Steve Sobol wrote:
>>>> In article<i9q0bo$u2r$>,
>>>> says...
>>>>> MS essentially killed off their own Java implementation as well, and
>>>> no one
>>>>> noticed.
>>>>
>>>> That was different. Microsoft Java was a bastardized version of Java
>>>> based on a 1.1 JVM with some M$-specific extensions.
>>>
>>> Not only extensions.
>>>
>>> Also a few things removed that MS did not want there.
>>>
>>> The latter has a pretty bad impact on portability.
>>
>> So do non-standard extensions: developers use them (sometimes
>> unwittingly) and then their code isn't portable to the whole rest of
>> the world.
>
> True.
>
> But that happens all the time both in Java (and other languages).
>
> A standard does not prevent non-portable code. A standard makes it
> possible to write portable code.
>
> You can avoid using non standard extensions and other ways of writing
> non-portable code.
>
> You can not do anything to protect against somebody not implementing the
> full standard.

You can not do anything to protect against another developer using a non
standard extension.

On Thu, 21 Oct 2010 23:37:24 -0700, Steve Sobol wrote:

> In article <i9r3le$if7$>, zjkg3d9gj56
> @gmail.invalid says...
>>
>> On Thu, 21 Oct 2010 11:21:42 -0700, BGB / cr88192 wrote:
>>
>> > admittedly, I don't (entirely) disagree with some of MS's
>> > re-engineering, and also think that, technically/overall, the .NET VM
>> > architecture is a little more sensible than the standard JVM
>> > architecture
>>
>> It can't be. It came from Microsoft.
>
> Microsoft doesn't necessarily equal Suck.

What you say?!

> Occasionally, they do a decent job.

Of marketing. But when it comes to software development ...

> I've always liked MapPoint, for example. Very capable piece of software.

Obviously you've either not compared it to any competitor or had amazing
luck of some sort with it. But luck will run out eventually and then
you'll be sorry. If you're still a little bit lucky it will only crash,
rather than lead you into a steep ravine in your non-4x4 sedan or
something.

> And, .NET is lightyears ahead of the technology it replaced.

If the criteria you use to measure software technology advancement is
"how much disk space does it chew up when you install it" then you could
be right.

> I never want to go back to VB6 or Classic ASP again

Who the hell would? Java/Clojure and JSP/Compojure are vastly
superior.

> I would note that with the .NET platform in general, Microsoft seems to
> have stolen a lot of ideas from Java. Not that that's a bad thing.

No, it's their polluting it with DRM and other bullsh!t, making stuff
proprietary, and all that crud that is a bad thing. There is still no
decent .NET runtime for Linux, but I don't care, because .NET = find
another alternative to me anyway for the most part.

In article <i9u1a0$5sk$>, zjkg3d9gj56
@gmail.invalid says...


> > And, .NET is lightyears ahead of the technology it replaced.
>
> If the criteria you use to measure software technology advancement is
> "how much disk space does it chew up when you install it" then you could
> be right.

Seriously?

You can't do diddly-squat with Classic ASP, for example. Many useful
things that you might want to do with an ASP script can't be done
without the use of third-party addons.

This is much less true with ASP.NET.


>
> > I never want to go back to VB6 or Classic ASP again
>
> Who the hell would? Java/Clojure and JSP/Compojure are vastly
> superior.


I'd rather program in Java, but I was comparing one Microsoft technology
to another.





--
Steve Sobol, Apple Valley, California, USA

On 23-10-2010 02:49, ClassCastException wrote:
> On Fri, 22 Oct 2010 18:50:47 -0400, Arne Vajhøj wrote:
>
>> On 22-10-2010 00:26, ClassCastException wrote:
>>> On Thu, 21 Oct 2010 22:23:59 -0400, Arne Vajhøj wrote:
>>>> On 21-10-2010 21:40, Steve Sobol wrote:
>>>>> In article<i9q0bo$u2r$>,
>>>>> says...
>>>>>> MS essentially killed off their own Java implementation as well, and
>>>>> no one
>>>>>> noticed.
>>>>>
>>>>> That was different. Microsoft Java was a bastardized version of Java
>>>>> based on a 1.1 JVM with some M$-specific extensions.
>>>>
>>>> Not only extensions.
>>>>
>>>> Also a few things removed that MS did not want there.
>>>>
>>>> The latter has a pretty bad impact on portability.
>>>
>>> So do non-standard extensions: developers use them (sometimes
>>> unwittingly) and then their code isn't portable to the whole rest of
>>> the world.
>>
>> True.
>>
>> But that happens all the time both in Java (and other languages).
>>
>> A standard does not prevent non-portable code. A standard makes it
>> possible to write portable code.
>>
>> You can avoid using non standard extensions and other ways of writing
>> non-portable code.
>>
>> You can not do anything to protect against somebody not implementing the
>> full standard.
>
> You can not do anything to protect against another developer using a non
> standard extension.

Ever heard of code review?

Arne

On 23-10-2010 01:23, BGB / cr88192 wrote:
> "Arne Vajhøj"<> wrote in message
> news:4cc2160b$0$23763$...
>> On 22-10-2010 03:48, BGB / cr88192 wrote:
>>> JNI and JNA leave a bit to be desired...
>>> having to use pre-existing classes or interfaces to interface Java with
>>> anything else is... lame...
>>>
>>> these are not unfixable problems, but thus far the major VM's have not
>>> done
>>> much to improve on them.
>>>
>>> even CNI (like GCJ) would be an improvement (just better would be not
>>> having
>>> to use GCJ to use it...).
>>> admittedly, this front is a little awkward...
>>>
>>> but, I am left to wonder sometimes if the poor interface mechanisms are
>>> maybe deliberate...
>>
>> It has certainly had the effect that the usage of JNI is rare.
>
> yes.
>
> Sun devises nearly the worst possible way to interface between C and Java
> and standardizes on it as a covert attempt to prevent people from plugging
> together C and Java code except in case of dire emergency...

I don't think SUN sees it as a problem.

And many Java developers neither.

We don't need this:
http://www.mono-project.com/MoMA



>>> OTOH, MS gives us P/Invoke and, better yet, C++/CLI. P/Invoke then
>>> provides
>>> a slightly less awkward way to glue the languages, and C++/CLI allows,
>>> more
>>> so, the ability to write code which sits right on the border...
>>>
>>> now, if this would be done without depending on MS's technology or
>>> dealing
>>> with the relatively poorer quality of the existing OSS VM's (and the
>>> apparent issue that C++/CLI is currently specific to MS's VM), this would
>>> be
>>> better.
>>
>> The MS C++ ability to generate mixed mode code is a very
>> sophisticated piece of technology.
>
> granted, but little says that it is outside the reach of a corporation with
> a pile of developers and money...
>
> FFS I have devised some vaguely similar pieces of technology (actually, more
> mixing compiler and interpreter technology, and using dynamic code
> generation to glue stuff together, but close enough, directly mixing
> bytecode and native code is the next logical step), and I am a lone hobbyist
> with neither endless supplies of time nor money. Sun could have probably
> done similar much more easily...
>
> after all, they did get the JVM itself working, and looking at it, improving
> the FFI would not have likely been anywhere as near a complicated of a task
> if they wanted to do so.

Of course SUN could have done it, but it would not have been cheap.

Arne

On 23-10-2010 03:02, ClassCastException wrote:
> On Thu, 21 Oct 2010 23:37:24 -0700, Steve Sobol wrote:
>> And, .NET is lightyears ahead of the technology it replaced.
>
> If the criteria you use to measure software technology advancement is
> "how much disk space does it chew up when you install it" then you could
> be right.

Depends on what decade ones PC is from.

It takes disk space worth 5-10 cent.

>> I never want to go back to VB6 or Classic ASP again
>
> Who the hell would? Java/Clojure and JSP/Compojure are vastly
> superior.

Since .NET replaced VB6 & ASP not various Java technologies
then that is not so relevant.

Arne

On Sat, 23 Oct 2010 21:12:58 -0400, Arne Vajhøj wrote:

> On 23-10-2010 02:49, ClassCastException wrote:
>> On Fri, 22 Oct 2010 18:50:47 -0400, Arne Vajhøj wrote:
>>
>>> On 22-10-2010 00:26, ClassCastException wrote:
>>>> On Thu, 21 Oct 2010 22:23:59 -0400, Arne Vajhøj wrote:
>>>>> On 21-10-2010 21:40, Steve Sobol wrote:
>>>>>> In article<i9q0bo$u2r$>,
>>>>>> says...
>>>>>>> MS essentially killed off their own Java implementation as well,
>>>>>>> and
>>>>>> no one
>>>>>>> noticed.
>>>>>>
>>>>>> That was different. Microsoft Java was a bastardized version of
>>>>>> Java based on a 1.1 JVM with some M$-specific extensions.
>>>>>
>>>>> Not only extensions.
>>>>>
>>>>> Also a few things removed that MS did not want there.
>>>>>
>>>>> The latter has a pretty bad impact on portability.
>>>>
>>>> So do non-standard extensions: developers use them (sometimes
>>>> unwittingly) and then their code isn't portable to the whole rest of
>>>> the world.
>>>
>>> True.
>>>
>>> But that happens all the time both in Java (and other languages).
>>>
>>> A standard does not prevent non-portable code. A standard makes it
>>> possible to write portable code.
>>>
>>> You can avoid using non standard extensions and other ways of writing
>>> non-portable code.
>>>
>>> You can not do anything to protect against somebody not implementing
>>> the full standard.
>>
>> You can not do anything to protect against another developer using a
>> non standard extension.
>
> Ever heard of code review?

So, maybe your boss can. You still can't.