OSNews

<sarcasm>
Or use morse code and punched paper tape- because progress sucks and there's no point in anything new.. right?
</sarcasm>

Honestly, I've had enough of your modernists with your fancy codes and paper tapes. OK, so stone tablets and chisels might not be quite as "sexy" but they get the job done and our storage longevity is excellent.

Is Java actually any more portable than Mono at this point?

The biggest difference in portability between the two that I can think of is that Java has an officially-supported-by-Apple port to Mac OS X.

- chrish

Yes, contrary to Mono, Java is everywhere.

There are Java implementations for:

- BlueRay players;
- Mobiles;
- Embeded systems (Cars, Ricoh copy manchines, Factory robots, and so on);
- All major OS;

And lets not forget that only the C# compiler and CLR are patent free, given the latest Microsoft announcement.

So with Java I have access to the complete library coming with the JVM, while with Mono I am restricted to the language and basic library.

How can they be incompatible if they pass the required tests to call themselves Java? if you're talking about proprietary extensions specific to a given implementation or libraries out side the specification then of course there will be incompatibilities - but that is only relevant if you're stupid enough to use those parts outside the official Java specification.



How the hell is that FUD? if you want assurance of being immune from patent claims then you have to stick to the ECMA stack - you don't have access to Winforms, asp.net, ADO.net and so forth. But hey, lying for you is a second language given you're versed in because you can't face the facts and speak the truth.



Based on what evidence - the code is all GPL'ed, how can they release code under GPL then pull it back? they might decide not give it a free compatibility test but who gives a toss, call it 'chocolate mochachino with cream on top' and people will still consider it a Java implementation.



Which is based on a nothing. The difference between you and I - I actually read some damn stuff before posting on this forum; I know the difference between the Microsoft arrangement which pertains to the ECMA implementation and the Java working group where people can freely implement it but cannot call it Java unless it has been certified. But then again, lying is your forte.



And that is supposed to be funny?

Edited 2009-07-19 04:55 UTC

Well, no - that certified compatibility is important. If a platform has a certified JVM implementation available, as a developer I can confidently say our product will run on it. If all it has is something Java-ish, I assure you, I'm not touching that with a ten-foot pole. Too much chance of something going wrong, and me having to support it.

Amazing how that has impacted on JBoss taking off, people are really shying away from IceTea and all those other open source projects apparently dying spontaneously through the lack of 'certification'.

Certification is no more important than Linux getting the blessing of it being SUS2003 or Mono being blessed as 100% compliant. Even if the implementation does pass the test, it still doesn't negate the fact that there could be vendor specific bugs that'll cause problems; so certification doesn't equal absolute perfection nor does certification claim as such.

>>So with Java I have access to the complete library
>>coming with the JVM

With IKVM/mono you can invoke classes from java jars, or compile jars into a CLR dll. It works pretty darned well. Also C# P/Invoke is a lot easier than JNI, which means you've got access to C++/java/C#/python/F#,VB in a single stack.

For the last few years I have been leaning toward C#, but I reserve the right to use java.

Yes, since going by their supported platforms list, Mono supports Linux on quite a few hardware platforms, but it's support for other OS's is limited mostly to x86. It won't run under HP-UX/Itanium, for example, or AIX/Power - operating systems common on big server hardware. Java does.

Mono has that option. Code can be compiled and loaded from .so files. The administrator can do it for system code or a user can set an environment variable with a directory to stash compiled code in.

Of course, the last time I tried using this (last year on x86-64) it made all Mono apps crash in strange random ways. I don't think it's been well tested.

It would work at first but later it wouldn't. It could have been prelink, or maybe Mono updated on my system and it didn't realize it had to recompile the code, or ...

Not sure about Mono, but speaking for Java here and in general about JITing.

There are several types of optimization algorithms and during the execution of you program the VM (JVM, CLR, and so on) might reach the conclusion that a certain piece of code would benefit from a different type of optimizations and so recompiles the code again.

For example it might conclude that in all places a certain method is called, actually it is always the same object instance, so the indirect method lookup can be replaced by a direct method call.

Or it might see that a certain method is called so many times, and since its size is small enough, it could start expanding the code inline, instead of doing a call.

And so on.

Neither Mono nor Microsoft's .NET runtime do this. They both behave the same as Java's client VM - JIT the code once, the first time it's called, and try to balance runtime speed with JIT time.

Java's server VM does as you describe. It's equivalent to using profile-guided optimization in C/C++ compilers, except it's automatic. It also turns on a lot of compiler optimizations that are too expensive to perform in an interactive application.

.NET doesn't have this. It does have an offline compiler, which pre-JITs an entire assembly with all the compiler optimizations turned on. The JIT doesn't do anything at all at runtime.

Any particular reason Mono doesn't always do pre-JITting?

Not sure. The pre-JITted native image is installed next to the CIL executable, so I assume it can't normally be done by a regular user - it'd have to be done at install time. You certainly can't run ngen on Microsoft's .NET implementation without admin privileges.

Pre-JITing requires the generated code to be a shared library. This is required so that the same code for say System.XML can be used in two different applications that might end up loading the pre-generated code at different addresses.

The code produced by shared libraries is a bit slower than static code. Invocations need to go through at dispatch table (In Mono and ELF systems it is called the PLT table) and access to global variables also has to go through extra steps and usually ties up a register to keep track of things.

So all of these things mean that you end up with code that might not be as efficient as the static code.

We essentially let the sysadmin make the call

So submit something!

not just that, llvm is an exciting piece of technology because its architecture allows for much better integration with the IDE (potentially allowing the actual frontend, or its components, be used instead of a scaled down parser, gaining more accurate code anlysis, code assistance and cumulative compilation);
because its IR bytecode and its runtime are language agnostic AND suit both managed AND unmanaged languages;
because it allows (at least on paper) either JIT'ed or AOT compiled code execution, and/or the optimization of code between runs;
and because it has the potential (though quite some manpower is needed to fulfill this) to be an alternative, instead of a complement, for mono and .net...

"...because if some one wants a really fast execution of code C/C++ has no match...?

really? every coded in assembly? portable? no. fast as can be? ya. check out http://www.menuetos.net/

True. But many computational guys are using a combination of c/c++ and python right now. Python for ease of use and c/c++ for performance. If you can improve the speed of your easy glue language, it can do more things, before having to be turned into the performance language. As non performance intensive as some of my work is, I've discovered a few places where it would seem like python would be okay, but its just really too slow.

Maybe Vala and Genie are a better choice for this stuff - Mono/C# (Vala) and Python (Genie) syntax but C speed.

Too bad on windows I have to use GTK (instead of Windows GUI-API) while using Vala or Genie, but besides that I'm happy with their progress.


P.S. the only thing missing is now a BASIC and a PASCAL frontend/parser and the circle would be complete...

Edited 2009-07-17 20:36 UTC

I can say that on my workgroup at CERN, part of the ATLAS project, we used a mix of everything.

C++ for the cluster based, multithreaded application that processes data coming out of the particle accelerator.

Python for the configuring the applications and doing some automation tasks.

Java for the GUI applications monitoring the cluster.