Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Apple is deprecating Java

Reply
Thread Tools

Apple is deprecating Java

 
 
ClassCastException
Guest
Posts: n/a
 
      10-22-2010
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$(E-Mail Removed)>, http://www.velocityreviews.com/forums/(E-Mail Removed) 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.
 
Reply With Quote
 
 
 
 
Steve Sobol
Guest
Posts: n/a
 
      10-22-2010
In article <i9r3le$if7$(E-Mail Removed)-september.org>, 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.

Occasionally, they do a decent job. I've always liked MapPoint, for
example. Very capable piece of software.

And, .NET is lightyears ahead of the technology it replaced. I never
want to go back to VB6 or Classic ASP again - both of those products are
utter crippleware compared to their .NET replacements.

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.


--
Steve Sobol, Apple Valley, California, USA
(E-Mail Removed)
 
Reply With Quote
 
 
 
 
BGB / cr88192
Guest
Posts: n/a
 
      10-22-2010

"Steve Sobol" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed).. .
> In article <i9r3le$if7$(E-Mail Removed)-september.org>, 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.
>
> Occasionally, they do a decent job. I've always liked MapPoint, for
> example. Very capable piece of software.
>
> And, .NET is lightyears ahead of the technology it replaced. I never
> want to go back to VB6 or Classic ASP again - both of those products are
> utter crippleware compared to their .NET replacements.
>
> 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.
>


yeah...

the main thing that is an improvement is supporting a lot more options for
interop with C and C++ code...

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...

delaying type-binding would be another possible solution (the code remains a
little more "fluid" until the last moment), allowing for code which is more
flexible WRT incomplete types.


for example:
package myapp;
public native class Foo;

then the compiler is like "ok, this class is not currently visible", but
uses it just the same (it handles methods and types a little more fluid than
usual, leaving pretty much everything about the class unknown until "a time
when it can be determined", likely either when linking the classes or at
runtime). the idea here is that the class would exist either outside the
language, or be implemented in some VM-specific way.

the problem though is that something like this is neither a good match for
the existing compilers nor for the bytecode (if the compilers supported it,
likely it would generate rather naive and inefficient bytecode, absent
something fancy being done in the JIT to try to compensate).

I guess the newer VM's are adding/have added an "invokedynamic" instruction,
but I have not looked into much as to how this would relate to this case.


I had intended to write my own compiler (for my own VM) partly to deal with
the above issue, but this is going very slow and I am left more using a
slightly more standard compiler (the Eclipse compiler) for the time being.

given this setback, I am still having to use JNI, but also partly devised
another mechanism for the meantime:
hacking over the JNI mechanism so that it is a little smarter, and can use
an alternate mechanism (trying to find a compatible match for 'native'
methods and trying to itself determine a sensible way to marshal the
arguments).

admittedly, using JNI some, it is not "as" terrible as it looks, but still
isn't really exactly nice or convinient either...

admittedly, my effort has a *long* way to go before "not sucking" is likely
(at the moment, it is more along the lines of "barely works at all"... as
both this aspect of the VM, and the class libraries, are woefully
incomplete).


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.

or such...


 
Reply With Quote
 
Steve Sobol
Guest
Posts: n/a
 
      10-22-2010
In article <i9rfjn$29b$(E-Mail Removed)>, (E-Mail Removed) says...


> yeah...
>
> the main thing that is an improvement is supporting a lot more options for
> interop with C and C++ code...
>
> 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...


But even with .NET you have a shim that allows you to deal with legacy
code.

With .NET you have the issue of managed code using legacy code.

With Java you have the issue of Java bytecode using native code, and
that isn't going to go away due to Java's cross-platformness.

JNI is a beast. I only use JNI if I need to create a native Windows or
Linux launcher for a program; otherwise, I use JNA. JNA is about as
simple as it's going to get, and it works well.


> these are not unfixable problems, but thus far the major VM's have not done
> much to improve on them.


Fixing said problems, IMHO, would entail getting rid of the *best*
reason to use Java (write once, run almost anywhere).



--
Steve Sobol, Apple Valley, California, USA
(E-Mail Removed)
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      10-22-2010
On Thu, 21 Oct 2010 09:08:29 -0700 (PDT), Xah Lee <(E-Mail Removed)>
wrote, quoted or indirectly quoted someone who said :

> As of the release of Java for Mac OS X 10.6 Update 3, the version
>of Java that is ported by Apple, and that ships with Mac OS X, is
>deprecated.


Apple is doing this all over. They now want to lock users in, and
ensure apps for Apple won't run or cannot be easily be made to run
elsewhere. Now they are getting bigger, they are mimicking IBM's old
strategies.
--
Roedy Green Canadian Mind Products
http://mindprod.com

Microsoft has a new version out, Windows XP, which according to everybody is the "most reliable Windows ever." To me, this is like saying that asparagus is "the most articulate vegetable ever."
~ Dave Barry
 
Reply With Quote
 
BGB / cr88192
Guest
Posts: n/a
 
      10-22-2010

"Steve Sobol" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed).. .
> In article <i9rfjn$29b$(E-Mail Removed)>, (E-Mail Removed) says...
>
>
>> yeah...
>>
>> the main thing that is an improvement is supporting a lot more options
>> for
>> interop with C and C++ code...
>>
>> 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...

>
> But even with .NET you have a shim that allows you to deal with legacy
> code.
>


yes, but one can write this shim in C++/CLI, and it is much nicer.

more so, not all C or C++ code is "legacy", rather it may be the case that a
large portion of the app is written, say, in C and C++, and Java or C# is
intended to be used as a high-level scripting language (along with
JavaScript and similar...).

hence Java can be used similar to Python, but less horridly nasty...


> With .NET you have the issue of managed code using legacy code.
>
> With Java you have the issue of Java bytecode using native code, and
> that isn't going to go away due to Java's cross-platformness.


the barrier can be lowered, however...

there is no good reason it has to be JNI, and the issue is with the design
of the standard JVM and compilers, rather than with the native code.

I have achieved *much* more transparent interfacing between a JavaScript
variant and C.
meanwhile, there is no good way even to plug together between Java and
JavaScript, even though the underlying implementation could do so without
issue.


> JNI is a beast. I only use JNI if I need to create a native Windows or
> Linux launcher for a program; otherwise, I use JNA. JNA is about as
> simple as it's going to get, and it works well.


JNA still has issues though, namely that it is wonky and can't deal with the
C ABI "on equal terms", and would seem to be a bit less powerful than JNI.

moving the interface gunk onto the Java side of things is not ideal either
(far from being transparent).
better would be if the VM was smart enough to "do the right thing" without
needing ugly gunk in either language (as in, transparent...).


>> these are not unfixable problems, but thus far the major VM's have not
>> done
>> much to improve on them.

>
> Fixing said problems, IMHO, would entail getting rid of the *best*
> reason to use Java (write once, run almost anywhere).
>


that is in the present case:
nearly every VM implements their own non-standard means to interface with C
(presumably in addition to JNI).


but, anyways, major options:
support delayed-binding in the compiler, and do some magic in the VM (this
was my original plan of action, but doesn't work so long as I am using a
standard compiler);
implement a less braindead alternative to JNI (which is along the lines of
what I have done for the time-being).


delayed-binding could allow binding with whatever is visible at the time,
essentially allowing transparently importing nearly the entire C toplevel
and typesystem de-facto (provided the implementation can see it), or gluing
against other languages (such as JS), but this can't be done with standard
compilers, or efficiently in the current bytecode design (absent hackery).
nevermind what level of evil hackery goes on behind the scenes.


the latter option basically looks just like JNI on the Java end (classes
with 'native' methods).
however, unlike JNI, the interface is capable of "negotiating" the arguments
with the C code (it looks up the C declaration, and sees what types it
expects, and also knows what exists on the Java end, and tries to figure out
how to best coerce the Java-side arguments into the C-side arguments).

it might also probe for different C-side functions, such as to make
interfacing a little more flexible.

technically, I just sort of hacked over the prior JNI mechanism and patched
it into other mechanisms elsewhere in the project (it looks up the proper
JNI function first, and failing this, falls back to the other options).


granted, I happen to be operating within the confines of a VM which knows
the C-side declarations for any functions/types/... and in some cases types
can have special modifiers attached (mostly these are used to give the VM
additional abilities to figure out C side types, such as when the object is
visible via a dynamically-typed reference or "void *" pointer, ...).

for example, in the interface, the 'this' argument is known by using a
special type which flags that a 'this' value is expected for this argument
(if omitted, 'this' is discarded).

so, for example:
public class Foo {
public native void bar(String str);
}

and in C, this could be used:
API void Foo_bar(dycThis self, char *str)
{
//captures 'this', and coerces the string to a C string
...
}

dycThis/dycObject/... are related to my framework's internal OO facilities
(sadly, these aren't transparently accessible from C either, and I am not as
inclined to do something along the lines of Objective-C nastiness to make it
work...). (partly this is because most of my C code is still compiled with
native compilers, as they tend to do the best job...).


but, this could be used:
API void Foo_bar(char16 *str)
{
//ignores this, coerces to a 16-bit string
...
}

or:
API void bar(char *str)
{
//treats it more like a toplevel function
}

or:
....

but, the above is a bit of a compromise, but at least, it provides a
slightly less ugly alternative...


the system is also capable of looking into structs, ... but there is little
hope of cleanly mapping this to Java (it is used with my JS variant though,
which is capable of looking into C structs).

as noted, types visible via "void *" pointers pose an issue, but my
framework also supports dynamic-type tagging, and it is common to indicate
(at the typedef's) that a given dynamic type name refers to a specific C
type, hence allowing dynamic typing on C structs (and type visibility
through void pointers).


on the Java end, something like this would require a wrapper class or
similar, say:
class TypedPointer extends Pointer {
...
public native int geti(String name);
public native long getl(String name);
public native float getf(String name);
public native double getd(String name);
public native Pointer getp(String name);
public native Object geto(String name);
...
public native void set(String name, int val);
public native void set(String name, long val);
...
}

or such...



 
Reply With Quote
 
Arne Vajhj
Guest
Posts: n/a
 
      10-22-2010
On 22-10-2010 11:06, Steve Sobol wrote:
> In article<i9rfjn$29b$(E-Mail Removed)>, (E-Mail Removed) says...
>> yeah...
>>
>> the main thing that is an improvement is supporting a lot more options for
>> interop with C and C++ code...
>>
>> 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...

>
> But even with .NET you have a shim that allows you to deal with legacy
> code.


If it is a Win32 DLL, then you don't need to write any glue code at all.

> JNI is a beast. I only use JNI if I need to create a native Windows or
> Linux launcher for a program; otherwise, I use JNA. JNA is about as
> simple as it's going to get, and it works well.


JNA still uses JNI.

It is just a convenience.

Arne
 
Reply With Quote
 
Steve Sobol
Guest
Posts: n/a
 
      10-22-2010
In article <(E-Mail Removed)>,
(E-Mail Removed)lid says...


> Apple is doing this all over. They now want to lock users in, and
> ensure apps for Apple won't run or cannot be easily be made to run
> elsewhere. Now they are getting bigger, they are mimicking IBM's old
> strategies.


And we all know how well that worked for IBM.




--
Steve Sobol, Apple Valley, California, USA
(E-Mail Removed)
 
Reply With Quote
 
Steve Sobol
Guest
Posts: n/a
 
      10-22-2010
In article <4cc1fcb8$0$23763$(E-Mail Removed)>, (E-Mail Removed)
says...


> If it is a Win32 DLL, then you don't need to write any glue code at all.


That wasn't my impression, but I don't do a ton of work with .NET, and
my code basically never needs to interact with a 3rd-party DLL. I could
definitely be wrong.

> > JNI is a beast. I only use JNI if I need to create a native Windows

or
> > Linux launcher for a program; otherwise, I use JNA. JNA is about as
> > simple as it's going to get, and it works well.

>
> JNA still uses JNI.
>
> It is just a convenience.


Granted. But using JNA means I don't have to use JNI directly, which
makes me happy, because JNI is butt-ugly.

The only time I use JNI directly is when I use the Invocation API to
launch a Java application from an .EXE.

I don't mean to imply that JNA is perfect, or that it isn't closely tied
to JNI.


--
Steve Sobol, Apple Valley, California, USA
(E-Mail Removed)
 
Reply With Quote
 
Arne Vajhj
Guest
Posts: n/a
 
      10-22-2010
On 22-10-2010 18:32, Steve Sobol wrote:
> In article<4cc1fcb8$0$23763$(E-Mail Removed)> , (E-Mail Removed)
> says...
>> If it is a Win32 DLL, then you don't need to write any glue code at all.

>
> That wasn't my impression, but I don't do a ton of work with .NET, and
> my code basically never needs to interact with a 3rd-party DLL. I could
> definitely be wrong.


If it is a Win32 DLL with a C API and the types are
not too tricky, then a simple DllImport attribute (annotation
in Java terminology) is all that is needed. .NET provides all
the glue.

Arne
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
deprecating T(V) as c-style cast for POD T in favor of initializationsemantics - Off topic kinda Gianni Mariani C++ 1 10-28-2008 02:45 AM
deprecating abstract methods Thomas Hawtin Java 5 04-17-2006 01:54 PM
Apple sues Apple over iPod GraB NZ Computing 2 03-29-2006 08:49 PM
Apple iPod trash, like all Apple products Rich DVD Video 8 02-27-2006 01:32 AM



Advertisments