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

[Haplo]

Oh, some things here, as requested.
1:Java has been altered to suit web development mainly, and while it  
does have disk access, that access is typically extremely limited and  
not too friendly with a lot of hierarchies.

2:Well, if you want to use eclipse as an example of a java based  
cross-tool, then I definitely say no. Eclipse is painful to use, even  
for languages that I'm familiar with.

3:Again back to OSX. Application and file bundles are essentially  
folders (although folders with information for the OS in their main  
level) that can contain all of the resources of an application (gfx,  
multi-lingual GUIs, the executable itself, data templates) in a way  
that can be accessed easily while maintaining an unprecedented ease  
of dealing with applications. What would have taken a whole directory  
(as in some games) is now a single file that can be dragged anywhere  
and simply doubled clicked to run as if it were just a normal  
executable. The advantages of this (well, at least in a gui based  
system, doesn't really matter for embedded) are numerous, and to list  
a few, it allows you to make an app with multiple translated versions  
in a single downloadable file (with only one copy of everything else,  
including the executable. You simply copy the GUI localizations for  
various languages and the OS selects the one to use based on the  
system language settings). This also essentially allows you to  
'embed' dlls within an 'executable file' so they can go with it  
wherever it might be moved while still retaining the advantages of a  
dll. The hierarchy of the folder puts the actual exe several levels  
down though, and java isn't too friendly with that format (although  
it can be used, OSX java applications are not nice to use).

Finally: The intrinsic overhead might be only 2%, but consider  
rosetta. The overhead itself isn't necessarily what causes problems  
or slowness, it's the consistent latency involved in translating  
before running, which slows down the process of branching by a large  
amount. a 2% overhead might incur a 40% speed penalty. Oh, and why  
does this matter for cross tools? Well, a java compiler isn't exactly  
to perform when compiling a large application (like.. say.. a  
compiler!). I say, if scheme has the stability/security features you  
were looking for in java, use that instead. Plus, scheme is fun to  
program in :P.

On Nov 27, 2006, at 10:01 AM, Jonathan S. Shapiro wrote:

> Okay, let's try to extract some facts here.
>
> On Mon, 2006-11-27 at 00:46 -0500, Haplo wrote:
>> 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),
>
> Which security features get in the way of application building?
>
>> fact that it requires a virtual machine,
>
> This is incorrect. Consider GCJ.
>
>>  the fact that it would also possibly require making GUI  
>> components to
>> work under coyotos (or at least not be ugly),
>
> If we plan to support Java at all, we need to solve this problem  
> anyway,
> but this isn't really relevant to the construction of our cross-tools.
>
>>  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)...
>
> I'm not sure what you mean here, and it seems to be worth  
> exploring. Can
> you expand on this?
>
>> There are very few useful things you can do with java that aren't
>> easier with C++
>
> Speaking with the benefit of 20 years and >4M career lines of code
> written in C++, this is complete bullshit. I certainly don't defend  
> the
> design decisions of Java, but for the vast majority of applications  
> the
> availability of GC and a viable exceptions model is extremely  
> important
> and useful. As a counter-example to your statement I would offer  
> OpenCM,
> where we decided to use the Boehm-Weiser collector to try to graft  
> these
> attributes back onto C++. It nearly destroyed OpenCM, which was
> otherwise rock-stable. Indeed, if I had it to do over today I would  
> use
> Java or C# for OpenCM [not C# yet, because mono isn't mature enough.]
>
>>  and all of those things still run faster in native compiled C++.
>
> Sometimes faster isn't the goal.
>
>>  I don't care what you say, virtual machines are inherently slow.
>
> First, this flatly isn't true. What you are seeing in the market today
> is virtual machines that are designed to do heavy optimization on
> long-running programs. These machines are being applied to programs
> whose dominant costs are their startup costs. It's an obvious  
> recipe for
> disaster. As a counter-example, consider our recent work on HDTrans,
> which basically shows that the intrinsic overhead of dynamic  
> translation
> is about 2%.
>
> However, I agree with your underlying point: current VMs are not very
> clever about precompilation or generating code quickly, and this is a
> problem.
>
> The main reason that I think this isn't an issue is the  
> availability of
> GCJ, which can perform purely static, ahead-of-time compilation.
>
>>  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.
>
> You might be interested to take a look at the HDTrans numbers.
>
>
> shap
>
> _______________________________________________
> 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/9c18b2b5/attachment.html