[coyotos-dev] Accept GCJ into the tool chain?

[Haplo]

I still say no. Support it? Sure, but as a widely used language for  
general applications? Java may have originally been designed for it,  
but the security features (created for web applications), fact that  
it requires a virtual machine, the fact that it would also possibly  
require making GUI components to work under coyotos (or at least not  
be ugly), and the fact that the application format for coyotos could  
be devised to be completely different from anything that could be  
easily done with java (while making life easier otherwise)... Simply  
not worth it. There are very few useful things you can do with java  
that aren't easier with C++ and all of those things still run faster  
in native compiled C++. I don't care what you say, virtual machines  
are inherently slow. You can compile some code to time some  
algorithms to find that out quite easily- native code is run directly  
while java code must run code to translate the java code which is  
then run, and even the best emulation will not run any CPU intensive  
task reasonably fast. Also, a virtual machine cannot be run on an  
embedded device, which is typically single-purpose and RAM is a huge  
constraint. The only things run there are maybe a single application  
and the kernel. My suggestion: make your own language or adopt some  
that are better suited to an extensible and custom created  
environment like coyotos. Objective-C works brilliantly well, but if  
people are reluctant about that, just make some C++ superset with  
features beneficial to development in the coyotos environment.

Here's my final take: if you can't (or wouldn't) write an operating  
system with it, then you don't need to be writing applications with  
it either (with only a very few exceptions, most of which are  
outdated). Chances are, there's a better language that you can do  
more with, do it faster, and have less problems with in the end.

Oh:
> Another thing about performance is that are lots of people doing java
> coding, but a little portion can write good code. It's a problem
> caused by java being sold as beginners/"average joe" language. Few
> months ago I had the mission to save a project. There was a task
> that used to take 1m40s to complete in a Palm Treo 650. That's
> prohibitive. Rewriting the code, now it runs in 4s. I've seen  
> things like
> these a dozen of times...
Palm pilots are not embedded devices. These are mostly designed to  
work like small computers (with graphics and a complete user  
interface). However, you would never write a single line of java code  
for an application on, say, a chip in your car, let alone one in a  
pacemaker. The VM would be larger than coyotos and the application  
designed to run on it combined, would cut the speed of the  
application in half, and if you tried to argue that it could be pre- 
interpreted, oops sorry, not enough RAM to do that on a real embedded  
device. Sure, you could add more RAM, or not, seeing how that drives  
up chip cost for no reason besides lazy retarded programming.

On Nov 26, 2006, at 11:38 PM, Daniel Simoes wrote:

> Hi. I never wrote before, but I feel obligated to contribute  
> because of
> my years of java embedded development.
> Sorry for my English, it's very poor. And, if I appear rude, it's
> actually lack of language fluency.
>
>> I don't suggest it. Java has a lot of problems, the biggest being  
>> that
>> java is /entirely/ decoded at runtime.
> What do you mean by decoded? Interpreted? Compiled? If it's  
> interpreted,
> that's not true. Modern virtual machines uses JIT compiling
> and hotspots performing very well. And by using GCJ you don't have  
> even
> a runtime compiling phase at all.
>> Java has always had the drawback of being slow, and even on MacOSX
>> where java is (or at least was) a major supported language for
>> applications, they were always notoriously slow and usually ugly.
> It was true three or four years ago.
> I've wrote a few mobile and desktop applications in the last years  
> that
> run in slow/low memory machines doing complex tasks
> like GIS/mapping performing very well. My first app was, in fact,  
> ugly.
> But then we switched to SWT and now there's no difference
> from native ones.
> Another thing about performance is that are lots of people doing java
> coding, but a little portion can write good code. It's a problem
> caused by java being sold as beginners/"average joe" language. Few
> months ago I had the mission to save a project. There was a task
> that used to take 1m40s to complete in a Palm Treo 650. That's
> prohibitive. Rewriting the code, now it runs in 4s. I've seen  
> things like
> these a dozen of times...
>> Furthermore, coyotos, as you have said many times, is supposed to  
>> find
>> its way into integrated applications, specifically in the medical
>> field for stability reasons. If you use java, any applications, many
>> of which will be sensitive, would be at the mercy of the virtual
>> machine. Do you really want applications like that to be forced to  
>> run
>> under code which is not your own?
> GCJ, open source virtual machines, etc...
> And, who told all the applications must be written in Java?
>> Also, java is a pain to develop with,
> It's a matter of taste... It's always a pain to use what you don't  
> know
> or don't have experience with. That argument is valid with Lisp, C+ 
> + or even
> Javascript.
>> and not well suited to applications running directly under the OS.
>> Even if you had some other language for your main applications, java
>> has still been proven very poor for that use.
> GCJ, JNI, vm customizations....
>
> Daniel Simoes.
>
> _______________________________________________
> coyotos-dev mailing list
> coyotos-dev at smtp.coyotos.org
> http://www.coyotos.org/mailman/listinfo/coyotos-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/coyotos-dev/attachments/20061127/8d870a8f/attachment-0001.html