>
> I will agree/add with my list below:
>
> 1. No runtime to install. (80 megs?)

JRE is about 5megs or so.

And as I've shown in this thread already: http://www.terrainformatica.com/org/j-smile/index.htm

j-smile-demo is

JavaVM + GUI ruintime = 200k.
Set of .class files of the demo app = another 200k.

All together  = 400k.

This example deomstrates that JavaVM can be made small enough
to be bundled with application code eliminating need of JRE at all.

> 2. JVM is a memory hogg.

Bad design of GUI libraries. Not more.

Andrew.

I use Visual Studio .NET 2003 with my customized version of DCoder. IMHO, it's easily more than just sufficient.

What is insufficient about it?  Simply the fact that the debugger and such do not mesh?

-[Unknown]

> 
> I am using VS6 for D. Not ideal but pretty sufficient.
> 
> Andrew.

Andrew Fedoniouk wrote:
>> I will agree/add with my list below:
>>
>> 1. No runtime to install. (80 megs?)
> 
> JRE is about 5megs or so.
> 

I have the Windows installer for 1.5.0.06 on my hard drive, and it's precisely 16 779 392 bytes.

In article <dvk4a7$1utv$1@digitaldaemon.com>, Andrew Fedoniouk says...
>
>"U.Baumanis" <U.Baumanis_member@pathlink.com> wrote in message
>>>
>> Well, there are hundreds of Java/Swing applications. :)
>> Take a look at http://java.sun.com/products/jfc/tsc/sightings/
>
>I knew that you will show me this page.
>
>You've missed capital letter A in Applications.
>
>How to explain what I mean?
>
>Well, the most popular Java IDEs were built on
>everything but not Swing.
>I think this fact can be an illustration of what I mean.

Well, Netbeans one of most popular Java IDE built on Swing.


>Swing is a child of academic development and is primarily
>used in univercities for educational purposes.
>Swing is conceptually best toolkit - classical I would say.
>But only in theory, practical implementation is far from ideal - to heavy
>to be used in real life.

I use Swing daily to write applications. They are fast, responsive, easy to
maintain, and clients don't have any issues with speed. :)
It is really conceptually very good and speed is the last thing to chose D (with
DWT?) over Java/Swing. Well, I am not OS/kernel developer. :)

>
>About Java GUI practical implementation:
>
>Here is my proof of concept:
>http://www.terrainformatica.com/org/j-smile/index.htm
>This is my JavaVM running typical GUI tasks.
>System of classes of this micro GUI  is close to Swing
>Even this small example shows that Java could run GUI
>successfully but for some reasons nobody really wants Java GUI.
>

nice work! :)

--
ub

"Jari-Matti Mäkelä" <jmjmak@utu.fi.invalid> wrote in message news:dvk2v1$1rf1$1@digitaldaemon.com...
> Using VMs is not a solution, it's a terribly perverted workaround. The real problem is that current operating systems are far too monolithic and hang/corrupt the whole machine when one unfortunate process dies/does something bad.

I agree. The job of the operating system is to sandbox processes so that when one dies, it is isolated from all the others, which it does a reasonably good job doing (but it could do better). The CPU hardware certainly is set up to support this. You can even run Windows entirely in a virtual machine!

In article <dvjlj0$pk0$1@digitaldaemon.com>, David Medlock says...
>
>Tom wrote:
>> Walter Bright wrote:
>> 
>>> I'm no expert on Java programming, but I get this question a lot: "What compelling reason does D have that would entice a Java programmer to switch to D?"
>>>
>>> I know several of you have come to D from Java, and are expert Java programmers, so you folks' reasons would be very valuable.
>> 
>> 
>> Java
>> - Sucks 'cause of its horrendous slowness
>
>This hasn't been true in quite some time.
>
>Check Javas position relative to C++ here: http://dada.perl.it/shootout/craps.html
>

Here's a later version of that benchmark 'suite': http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=all

Along with the resurrected tests from the site above (note that this site as uniform 'weights' for all of the tests that don't benefit one language over another): http://shootout.alioth.debian.org/old/benchmark.php?test=all&lang=all

IIRC, there was some argument a while back that they weren't running the tests long-enough to take advantage of Hotspot. Since then they've increased the length of the tests to account for that (and startup time is subtracted from those results as well, I believe).

Of course, these being benchmarks, take everything with a grain of salt <g>

IMHO, the purpose they best serve is to point out potential weaknesses to implementors, but anyway...

>
>I will agree/add with my list below:
>
>1. No runtime to install. (80 megs?)
>2. JVM is a memory hogg.
>3. Much better low-level facilities(OpenGL, bit twiddling)

Jari-Matti Mäkelä schrieb am 2006-03-19:
> james wrote:
>> Also there seems to be two major approaches to app development emerging:
>> Java/c# and a virtual machine
>> VS
>> c/c++/D and scripting languages like ECMAScript, Python, Lua.
>> 
>> I think the latter is the way to go. And the fact that DMDScript(ie ECMAScript) is written in D is great.
>
> Using VMs is not a solution, it's a terribly perverted workaround. The real problem is that current operating systems are far too monolithic and hang/corrupt the whole machine when one unfortunate process dies/does something bad. Modern micro/exokernel OS:es (see demo.tudos.org), a safe native code low/high-level hybrid-language (D, of course) and some high-level scripts on top of that is a lot more flexible and effective approach. Having a true modular kernel actually means that the VM is kernel-level stuff and it's always on. Huge improvement IMHO.

One huge advantage of VMs is their design:
* lot's of prior experiences with all sorts of architectures and
libs

* a clean sheet, thus no cludges for supporting applications from the parent architecture

* a strong seperation between normal applications and the used hardware(including the CPU) -> "smart" phone applications

* most important: the potential to design according to todays
requirements and available technology instead of those from
the 70th and 80th
(the C99 standart only specifies how to access files but not
how to list directories?!)

There are domains where VMs make sence, but you are right
a secure modular kernel could be used in most places where
Java and .NET are currently used. One nice point about
the Java and .NET runtimes are the large amount of
OS/architecture agnostic tools/objects/functions.

Thomas

And that's assuming you can use that specific version of the runtime with the specific version of the Java program you want to use.

Otherwise it's another 16 megabytes.  And the large updates you're always prompted to install.

Unpacked it's significantly larger, but I realize most people these days don't care if their simple text editor requires 200 megabytes of hard drive space.

-[Unknown]


> Andrew Fedoniouk wrote:
>>> I will agree/add with my list below:
>>>
>>> 1. No runtime to install. (80 megs?)
>> JRE is about 5megs or so.
>>
> 
> I have the Windows installer for 1.5.0.06 on my hard drive, and it's precisely
> 16 779 392 bytes.

"Dave" <Dave_member@pathlink.com> wrote in message news:dvkbvk$2hn5$1@digitaldaemon.com...
> IIRC, there was some argument a while back that they weren't running the
> tests
> long-enough to take advantage of Hotspot. Since then they've increased the
> length of the tests to account for that (and startup time is subtracted
> from
> those results as well, I believe).

I attended a seminar at SDWest which talked about the "myth" of slow Java. Turns out, the code is interpreted for a while, then it gets compiled, then certain things can *invalidate the compiled code* so it goes back to interpreting it, then compiling it again, etc.

Is it invalid to include all these compile times, even if they occur well into the execution, as part of the benchmark time? I don't think so. At the end of the day, the time the user is sitting their waiting is what matters, and that will include all the startup, interpretation, compilation and recompilation times.

The presenter confidently predicted that in 10 years, Java will outperform C in the general case. Color me skeptical.

U.Baumanis escribió:
> In article <dvk4a7$1utv$1@digitaldaemon.com>, Andrew Fedoniouk says...
>> "U.Baumanis" <U.Baumanis_member@pathlink.com> wrote in message 
>>> Well, there are hundreds of Java/Swing applications. :)
>>> Take a look at http://java.sun.com/products/jfc/tsc/sightings/
>> I knew that you will show me this page.
>>
>> You've missed capital letter A in Applications.
>>
>> How to explain what I mean?
>>
>> Well, the most popular Java IDEs were built on
>> everything but not Swing.
>> I think this fact can be an illustration of what I mean.
> 
> Well, Netbeans one of most popular Java IDE built on Swing.
> 
> 
>> Swing is a child of academic development and is primarily
>> used in univercities for educational purposes.
>> Swing is conceptually best toolkit - classical I would say.
>> But only in theory, practical implementation is far from ideal - to heavy
>> to be used in real life.
> 
> I use Swing daily to write applications. They are fast, responsive, easy to
> maintain, and clients don't have any issues with speed. :)
> It is really conceptually very good and speed is the last thing to chose D (with
> DWT?) over Java/Swing. Well, I am not OS/kernel developer. :)

:0
What!? Speed IS a known issue the same as it is memory consumption. If there is speedy apps written in Java, then those are the least. Or at most, to write quick apps in Java is pretty difficult.
Maybe I have the wrong impression but there has been hundreds of _desktop apps_ I've reviewed and 95% of them are just *slow*.