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

[Jonathan S. Shapiro]

Haplo: concrete facts, please!

On Mon, 2006-11-27 at 14:18 -0500, Haplo wrote:
> 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.

Can you expand on the disk access issue? What is the concrete problem?

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

That sounds like an objection to eclipse, not an objection to Java. I
wasn't defending Eclipse. I was merely using it as an example of a
(very) large application written in Java that runs fairly well when
statically precompiled.

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

Okay. I understand about bundles, and I understand why a VM-based java
implementation would have difficulties with this. I do not see this as
an objection to Java as a language or to statically compiled Java code,
which should function (at least) as well as (e.g.) Objective C code.

Personally, I've never liked the bundle notion, but that's a separate
discussion.

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

When I write that "the intrinsic overhead is only 2%-3%", I'm
*including* the translation overhead. I definitely agree that the
rosetta implementation stinks.

But this is an objection to dynamic translation, which isn't relevant to
the question at hand.

shap