@jaokim

Hello Jaokim...

Nice to see you here.

In the recent past you got new goals any two months, so I found strange this long silence of you.

Hope you will get new achievements in jamiga as soon as possible, compatible with "real life" situation.

_________________
"When the Amiga came out, everyone [at Apple] was scared as hell." (J.L. Gassée, former CEO of Apple France and chief of devs of Mac II-fx, interviewed by Amazing Computing, Nov 1996).

@Hypex

Quote:

I don't know why. Years ago banks used Java and so you couldn't use an Amiga browser for those sites. Then things relaxed and Java started to become JavaScript where we did have support.

IMHO Java shouldn't be used at client side. I can't speak about the rest of countries but at least in Spain Java&Cobol are both used on server side to process all the transactions in 99% of banks.

Quote:

they introduced JavaScript JIT compilers

Bigfoot is working hard on giving us a nice Javascript JIT for Oddisey (MorphOS).

Quote:

Native code should be the best.

If all electronic devices capable of browsing web pages used same cpu it would be great, but since manofacturers use various cpu families we as amigans have the chance of browsing these pages targetted to users that own x86/arm hardware thanks to the lack of native code.

There are some nice apps written in Java like Eclipse. And an important part of Android apps are also developed using Java.

Java is interesting if your software has to run on different architectures&OSes. But it's not as portable in the end... there are differences between different JVM, Java versions, propietary third party libraries only designed to run on certain JVMs...

Java in certain ways protects you from not very careful programmers that don't free resources (due to garbage collector), from those that don't know how to work with pointers, from those that don't modularize their code.

C++ allows you to do almost everything you can do on Java but you can also break the "rules" more easily. If your C/C++ code is portable you should be able to run it without much trouble but you will need more skilled programmers.

Finding skilled C/C++ programmers is harder than finding Java ones that don't make your app go kaboom. Don't get me wrong, you can also write rubbish Java code but its consecuences aren't as destructive as in C/C++.

All in all we have to adapt to the market/computing world.

I would love to be able to run Eclipse on AmigaOS/MorphOS (you can use it to produce C/C++ code too). Visual Studio would be nice too with a .net vm and adapted classes. Well, at least we can crosscompile

Last edited by Crumb on 15-Feb-2015 at 10:37 PM.

_________________
The only spanish amiga news web page/club: CUAZ

No, I agree, Java shouldn't, in general (there are usages where it's acceptable) be used for client side web applications. The reason it was (and is) being used by banks, I think is due to the Java application having access to the local computer, whereas JavaScript is only able to access files and such after they've been uploaded by the user and processed by the server (JavaScript can only modify the DOM of a web page, nothing else). A Java applet can access basically anything a native application could. Also a Java applet could be updated automatically by the server side, without the user needing to do anything, and the user would not be able to use an old application, since it is downloaded each time (there might be some caching issues). A Java applet should when discussed be compared to ActiveX-components, rather than JavaScript (the only thing JavaScript and Java has in common are the three letters J A And V).

As for comparison to C++ (not C), freeing resources is only necessary when you use "new". You can create C++ programs by only creating local objects and sending them as references, and not pointers.

I'm not saying that Java is better than C or C++, I'm just saying that it isn't worse, and in many cases can be better. But then, I'm biased.

_________________

@jaokim

As a end-user and part-time developer I support any initiative to port/bring any language or framework to the Amiga.
That may include Python, Java, Lua, Qt...

Actually, I don't think I'm even legit to question the relevancy of your work here.
You decided to spend some of your free time to bring Java to the Amiga (is that right?), then, so be it, thanks for your effort and have fun! :)

_________________
fra.planet-d.net | www.emucamp.com/

I understand that Eclipse is a desktop thing running on Java. I'd love to see that come over to Amiga, as a great deal of stuff builds on Eclipse. (Far more than just a Java IDE now)

_________________
All glory to the Hypnotoad!

@Hans

Quote:

Hans wrote: @Jupp3 Quote: Jupp3 wrote: @Raffaele If this project doesn't start progressing seriously fast soon, there's a danger that Java will die off completely before we get to use it! (On web, it's already practically dead) On the web-browser side, perhaps, but you'd be surprised how many websites/web-services are written in Java. Also, Android apps are usually written in Java. Google do provide a "Native Dev. Kit" for those who want to create fully native apps, but they discourage it's use. From the NDK webpage: Quote: Before downloading the NDK, you should understand that the NDK will not benefit most apps. As a developer, you need to balance its benefits against its drawbacks. Notably, using native code on Android generally does not result in a noticable performance improvement, but it always increases your app complexity. In general, you should only use the NDK if it is essential to your app—never because you simply prefer to program in C/C++. Hans

Google doesn't discourage NDK usage, but warns developers about the complexity and drawbacks of such decision.

Actually there are about 1,5 million Android applications, and around 10% of them are "native". 150K applications can be considered a low number, compared to the vast majority that uses Java, but most of the TOP100 downloaded and sold applications on the Google store are native.

The reason is quite simple: (important) games are usually written with the NDK, because using Java brings sub-normal quality and worse user experience. In fact, it's clearly reported on the NDK page that you provided:

Quote:

Typical good candidates for the NDK are CPU-intensive workloads such as game engines, signal processing, physics simulation, and so on.

Another important reason for some non-games to use NDK is to easier the portability to other platforms: you put as much code as possible in some common libraries, and leave the rest to the specific presentation layer of the application. Also this is reported on the NDK page:

Quote:

For certain types of apps, this can be helpful so you can reuse existing code libraries

@Hypex

Quote:

Hypex wrote: @Hans Quote: On the web-browser side, perhaps, but you'd be surprised how many websites/web-services are written in Java. I don't know why. Years ago banks used Java and so you couldn't use an Amiga browser for those sites. Then things relaxed and Java started to become JavaScript where we did have support. And now things like Facebook kill us off again because it became too slow and they introduced JavaScript JIT compilers to compensate where now most sites are only useable on an 8 core CPU. What the hell!! They already had Java which could be compiled to CPU code efficiently, why would they want to compile a script into tokens and then render it to the CPU?! To give the latest Intel somnething to do? I don't understand the modern internnet world.

Abstraction has a (big) cost, unfortunately.
Quote:

Quote: Google do provide a "Native Dev. Kit" for those who want to create fully native apps, but they discourage it's use. I wonder why that is. Native code should be the best.

Not always. Once you compile an application, the code is immutable: you cannot change it, whatever is the architecture on which it runs. Non-native applications, instead, can be JIT-ed emitting proper binary code for the specific architecture. Last but not least, the generated code can be profiled at runtime, and a new, more optimized, code can be changed according to collected statistics.

There is a lot of research in this field, but you can take a look HP's Dynamo project if you want to get a good overview on the argument.
Quote:

And if they don't like people using it why did they release it?

That's not true, in fact. See above.
Quote:

I haven't seen Android run on anything other than ARM,

Currently Android supports ARM (v6 and v7 for sure; I don't remember now if even v5 is supported. v8 is coming), Intel (IA-32 and Intel64), ad MIPS (MIPS32). There are several Intel IA-32 and Intel64 devices already available. I don't know about MIPS ones.
Quote:

but if slight CPU differences can be a problem where even user code cannot remain compatible, then I can see the benefit of agnostic bytecode.

It has benefits, of course. Native applications are also much harder to develop, so they have an higher cost for a software house. Java is much easier and fast to develop: that's why about 90% of Android applications use it.

@Crumb

Quote:

Crumb wrote: @Hypex There are some nice apps written in Java like Eclipse. [...] I would love to be able to run Eclipse on AmigaOS/MorphOS (you can use it to produce C/C++ code too).

Eclipse is an horrible IDE IMO: it's a chaotic patchwork. The only advantage that I see, is regarding its HUGE plug-ins library.

Staying to Java, IMO NetBeans is a much better IDE, very friendly and well organized. It has also a good plug-ins library.
Quote:

Visual Studio would be nice too with a .net vm and adapted classes. Well, at least we can crosscompile

That would be the best, and Microsoft announced that the next versions will support cross-platform development for iOS and Android.

Recently it has also announced the Community Edition (VS2013CE is the first of the series), which in short means that the Professional Edition is now free to use for anyone.

Writing plug-ins for Visual Studio isn't difficult, so one can be implemented to support cross-development for Amiga and post-Amiga machines. Remote debugging should be an awesome feature.

Maybe a bounty for it can be opened.

@jaokim

Quote:

jaokim wrote: No, I agree, Java shouldn't, in general (there are usages where it's acceptable) be used for client side web applications. The reason it was (and is) being used by banks, I think is due to the Java application having access to the local computer, whereas JavaScript is only able to access files and such after they've been uploaded by the user and processed by the server (JavaScript can only modify the DOM of a web page, nothing else). A Java applet can access basically anything a native application could. Also a Java applet could be updated automatically by the server side, without the user needing to do anything, and the user would not be able to use an old application, since it is downloaded each time (there might be some caching issues). A Java applet should when discussed be compared to ActiveX-components, rather than JavaScript (the only thing JavaScript and Java has in common are the three letters J A And V).

A Java applet runs on a sandbox by default.

A Java application can be run on a sandbox also: http://stackoverflow.com/questions/502218/sandbox-against-malicious-code-in-a-java-application