Apple is deprecating Java

A

Arne Vajhøj

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
 
A

Arne Vajhøj

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
 
B

BGB / cr88192

Arne Vajhøj said:
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.


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

ClassCastException

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. :)
 
C

ClassCastException

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

Steve Sobol

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.

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

Arne Vajhøj

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

:)
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
 
A

Arne Vajhøj

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

ClassCastException

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.

So ASP.NET is slightly less awful than ASP, while still being lightyears
behind cutting edge non-Microsoft technology. Hmm.
 
C

ClassCastException

Depends on what decade ones PC is from.

It takes disk space worth 5-10 cent.

The cost of the disk space was immaterial.
Since .NET replaced VB6 & ASP not various Java technologies then that is
not so relevant.

Eh, they're all ways of serving dynamic server content. From the user's
perspective it makes no difference as long as the thing speaks plain
understandable HTTP 1.1/HTML 4.0 Transitional to their web browser.

If you have an existing site you're upgrading it might be a colossal pain
to cross-migrate to some other platform. Especially from an MS to a non-
MS platform. Though if your content is all in a DB and the DB speaks
standard SQL that will help.

If you're considering creating a whole new site, I can think of so many
reasons NOT to use .NET that I can't figure out why anyone DOES. It's
suckier and more expensive and unlike a desktop user getting a new PC
that comes with Windows right out of the store it's not simply the almost-
unavoidable default that's actually more up-front work and expense to
change than to stick with. Nor is it more compatibility headaches. The
home Linux route, though it can be rewarding, is admittedly fraught with
hardware (less than used to be the case) and software/data compatibility
issues whereas Windows Plug-n-Pray admittedly mostly "just works" these
days. On the other hand, on the server side as long as you speak standard
HTTP and HTML and SQL there should be no compatibility issues among your
web server, your database, and your end users' browsers.
 
M

Mike Schilling

ClassCastException said:
So ASP.NET is slightly less awful than ASP, while still being lightyears
behind cutting edge non-Microsoft technology. Hmm.

ASP.NET isn't cutting-edge .NET technology, having been superseded by WCF
three or four years ago.
 
A

Arne Vajhøj

ASP.NET isn't cutting-edge .NET technology, having been superseded by
WCF three or four years ago.

????

ASP.NET web services has been somewhat superseeded by WCF.

ASP.NET win form web apps has only been supplemented by
ASP.NET MVC web apps.

Arne
 
B

BGB / cr88192

Arne Vajhøj said:
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

:)

JNI is kind of lame when dealing with a largish mixed language codebase (big
mix of parts of the app written mostly in C and C++, some parts in Java, and
other parts in a custom ECMAScript/JavaScript/ActionScript style
language...).

in my case, I have more recently gotten my own Java implementation mostly
into basic working order, but I am still building with Eclipse's compiler,
and due to minor technical issues am still left using JNI for this stuff (I
am also sort of using my own half-assedly kludged together class library,
and this is the main place I am running face-to-face with JNI).

it is usable, at least, but far from being painless either...


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

this is back to the whole "vision" thing.

Java was seen as a framework for creating and distributing
architecture-neutral apps...
to this extent, it works well enough...


however:
totally left out of the mix is people who are mostly building C and C++
apps, but want something more capable and less terrible than the likes of
using Python or similar.

I suspect probably Sun didn't really want people writing mixed apps, and
using Java as a scripting language, since this would hinder its use in the
above category (as an app-distribution platform).

JNI seems to be designed in such a way to make this particular usage pattern
somewhat awkward (one has to use the JNIEnv pointers which are not
gueranteed to be valid if saved between calls, ...), and AFAIK there is no
external C-side API, ...

nearly everything seems designed with the idea in mind of it being a
self-contained platform.

but... not everyone wants or needs such a "platform".


but, for scripting, I would much rather be using Java than Python at
least...

Python probably has done as well as it has because it spawned up within a
niche where relatively little strong competition existed at the time (apart
from Scheme). it wasn't until recently that JavaScript really became a
viable general-purpose option (for most of its life, JS was largely confined
to browsers, apart from those of us maintaining their own implementations,
....).

now, of course, this niche (in general) has a bit more competition.


back to the late 90's, I had been using Scheme, but due to frustrations with
the VM (Guile) went and wrote my own. by 2002/2003, this had become overly
complex, so I dropped the prior VM and language, and mostly started clean
with a JavaScript variant (2004).

in 2007, I started on a trek involving writing a C compiler for use as a
scripting engine.

in all of this, I developed quite a bit of dislike for nearly all forms of
writing boilerplate for sake of plugging native code and VMs, and even my
own JS-like language was standing on perilous ground for a fairly long time
until I devised better ways to plug it into C land (whereas there is Swig
for Python and similar...).

the main competition (for my JS variant): a dynamically-compiled C/C99
variant (my own implementation, mostly standards conformant). however, it
had its own drawbacks (mostly poor reliability and slow compiler
performance), and once the interface between my JS variant and C improved
(early 2010), I switched back most of my scripting efforts to using this JS
variant (a lot of the machinery used in my C-scripting and early JBC effort
were used in implementing this interface machinery).


finishing up my Java support (via running Java Bytecode) was more recent (I
started around 2009 but worked mostly on other stuff, and had been trying
for an compiler similar to my dynamic C compiler).

eventually, I gave in, and finished up on JBC support mostly as my
Java-compiler effort wasn't going very fast, and also because I felt some
need for an external bytecode (both my JS variant and C compiler have their
own internal, but very different, bytecode and JIT-style systems, and in
both cases the internals are very tangled in with both the bytecode and
compiler machinery, preventing then from being used as external "cannonical"
formats...).

basically, an externalized bytecode could offer an alternative to my current
heavy use of x86 and x86-64 assembler (the worry is that all of this ASM
poses a portability threat...).


and, JBC also offered a few possible capabilities that my other bytecodes
lack.

one was observed in getting the support working: it can be demand-loaded.

most of my prior stuff tended to have to be force-fed its input ("go load in
this big pile of crap which may or may not be useful"), with the JS variant
always recompiling everything, and the C compiler using trickery (dependency
checking, hash codes, and object caching) to allow skipping recompiling
modules which it has previously compiled (when compiling, it would save out
the code, and reload the previously code if the module was still
up-to-date). the above trick (hashes+deps) was used because the C compiler
was SLOW, and otherwise killed app startup times...


demand-loading is a somewhat different possibility...

this makes JARs and class files more sensible (originally, I had just
assumed bulk-loading all the classes and forcing them through, which would
still be problematic), as the volume of code, raw speed of the loader and
JIT backend, ... become much less important with demand-loading (since the
app startup time is not killed by trying to load in and JIT the entire class
library...).

or such...
 
A

Arne Vajhøj

JNI is kind of lame when dealing with a largish mixed language codebase
Absolutely.

this is back to the whole "vision" thing.

Java was seen as a framework for creating and distributing
architecture-neutral apps...
to this extent, it works well enough...
Yes.

however:
totally left out of the mix is people who are mostly building C and C++
apps,
Yes.

I suspect probably Sun didn't really want people writing mixed apps, and
using Java as a scripting language, since this would hinder its use in the
above category (as an app-distribution platform).
Yes.

JNI seems to be designed in such a way to make this particular usage pattern
somewhat awkward (one has to use the JNIEnv pointers which are not
gueranteed to be valid if saved between calls, ...), and AFAIK there is no
external C-side API, ...

What is "external C-side API"?

JNI certainly contains API for C->Java.
but... not everyone wants or needs such a "platform".

True.

Arne
 
A

Arne Vajhøj

The cost of the disk space was immaterial.


Eh, they're all ways of serving dynamic server content. From the user's
perspective it makes no difference as long as the thing speaks plain
understandable HTTP 1.1/HTML 4.0 Transitional to their web browser.

That does still not change the point that Steve was very specifically
comparing .NET with the MS tools it has replaced.

Arne
 
M

Martin Gregorie

JNI is kind of lame when dealing with a largish mixed language codebase
(big mix of parts of the app written mostly in C and C++, some parts in
Java, and other parts in a custom ECMAScript/JavaScript/ActionScript
style language...).
So why not structure the non-Java code as a server and write the Java
interface as a client that uses a Socket to talk to it? Simple to do,
simple to understand and fast if the server is on the same host.
 
B

BGB / cr88192

Arne Vajhøj said:
What is "external C-side API"?

JNI certainly contains API for C->Java.

basically, where one just includes against the headers and links against the
correct DLL or whatever representing the VM's external interface, and just
starts making direct API calls to control the VM (in the same way as say
POSIX or the Win32 GDI or similar, or when using basic features of OpenGL,
or most other C libraries apart from DirectX and similar...).

instead, one has to deal with everything via the JNIEnv and JavaVM and
jvmtiEnv structures and similar.

for example, if one could do things more like, say:
#include <javavm.h>

int main(int argc, char *argv[])
{
JVMContext *ctx;
int i;

jvmInit(argc, argv);
ctx=jvmCreateContext();
jvmMakeCurrent(ctx);

...
jvmAddClassPath("%USERPROFILE%/Application Data/MyApp/bin");
jvmLoadLibrary("myclasses.jar");
i=jvmInvokeStaticI("myapp/MyClass/myMethod(I)I", 3);
...

jvmDeinit();
}

or similar...


probably, I guess, one could wrap JNI and JVMTI and similar to beat together
something like this if they really wanted, but oh well...

I made a partial wrapper before (implemented mostly via static inline
functions), but didn't end up using it so much, hmm...

clz=jniFindClass(env, "myapp/MyClass");
is not too much different from:
clz=(*env)->FindClass(env, "myapp/MyClass");


in my VM, the prior example was closer to how things may be done (although
the "init" function ends up doing main-hijacking and recalling back into the
function given technical issues WRT the GC).

from a VM-test stub:
<--
#include <bgbjvm.h>

int main_argc;
char **main_argv;

int main_i()
{
void *args[16];

printf("Mark 0\n");
BJVM_Init(); //bring up VM

printf("Mark 1\n");

// *(int *)-1=-1; //usual trick to do a controlled crash

BJVM_GetLoadedClass("HelloTest"); //load the test
BJVM_GetLoadedClass("java/lang/System"); //load the class early
//note: BJVM_Init(); implicitly loads "java/lang/String" by itself
//it also pulls in the class library/... (currently hard-coded)

printf("Mark 2\n");
args[0]=NULL;
BJVM_InvokeStaticMethodU(
"HelloTest", "main", "(QLjava/lang/String;)v", args);
//above: call method: note, my VM internally uses different signature
notation from the JVM
//main JNI interface fakes proper JVM sigs though...
}

int main(int argc, char *argv[])
{
main_argc=argc;
main_argv=argv;
dy_init2(main_i); //GC related, brings up VM core facilities as well
}
-->


although in some cases I end up using a lot of interface structs as well as
a way of interfacing with the VM without hard-linking against the DLL, and I
actually provide 2 different implementations of JNI, which differ mostly in
terms of which DLL exports the interface and how much effort was put into
faking the JVM's behavior.

some amount of my library code just uses JNI though, rather than
sidestepping it and relying on the underlying implementation details.


JNI is not ideal, but as noted elsewhere, it does work.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top