
The End of IKVM.NET - curtis
http://weblog.ikvm.net/2017/04/21/TheEndOfIKVMNET.aspx
======
blinkingled
[https://mobile.twitter.com/JeroenFrijters/status/85506465430...](https://mobile.twitter.com/JeroenFrijters/status/855064654309199872)

This conversation between Miguel De Icaza and the author doesn't look too
favorable for the author.

~~~
moomin
To be honest, though, I think the author recognises that, which is why he
specifically praises MdI in his post. Knowing that he's tired and just plain
pissed-off with both platforms explains both. You're right, he doesn't come
out of it well, but I've certainly had days and even months when I've felt
like that, and he's making the right decision: he's moving away from something
that is, for him, toxic.

~~~
blinkingled
> he's making the right decision: he's moving away from something that is, for
> him, toxic.

No argument there. After working 15 years on something non trivial it's
totally ok to get fatigued and bail out. I was pointing out that there doesn't
seem to be a valid technical argument to it.

------
skrebbel
IKVM has saved my ass a number of times. The ability to, at times, give up on
the .NET ecosystem and peek into the Java ecosystem for suitable open source
is fantastic.

We once had a project where some genius long ago had mandated that parts
communicate _via FTP_. Eg one program uploads a file, another program monitors
the directory. Total clusterfuck, so we wanted reliable automated tests. Turns
out that doing an FTP server in .NET is pretty difficult. Full-fledged
commercial libraries exist, but we just wanted a stub for testing.

IKVM, Apache Mina FtpServer solved it in two hours for us. I suspect many .NET
shops use IKVM this way.

Sad to see it go, but it must've been an incomprehensibly huge one man hobby
project for 15 years! If I were Jeroen I'd quit a long time ago :-)

Let's hope some shops get sufficient value out of it to maintain a fork.
Jeroen if you read HN, thanks!!

~~~
nurettin
We have the same setup at our place. FTP communication isn't a "clusterfuck",
it is the tried and tested communication method between any two large
companies that aren't banks. To us, it is the only highly available and
reliable one. Web services have downtimes and re-sends. Our partners
practically never turn off their FTP machines.

The only difference at our place is that we assume FTP works and do our tests
on the file system. We don't test whether FTP works. We know it does.

~~~
skrebbel
How did you deal with large files, dropped connections, and so on?

I mean, sure, FTP the protocol works fine, and so does virtually all FTP
software, but for communication it lacks an important feature: the ability to
tell when a file completed uploading.

When we started to upload reasonably large files on reasonably fast file
systems this became problem. Our file watcher noticed that a new file arrived,
but it's just _started_ uploading. We tried polling the FTP server for
connection status, but it turned out that the client supported and did at time
use, resumed uploads on connection drops. We ended up having to parse each
file just to tell whether it had finished uploading. The file fortunately was
an enormous XML dump, so we could check completeness pretty cheaply.

All of this work would've been avoided with a transactional protocol such as
HTTP.

~~~
tvjames
I've almost exclusively seen this handled using an upload with a temporary
filename (usually convention based) and then renamed on completion. Watch then
for the existence of the renamed files. Clean up temp files after a defined
amount to time (30 days for example).

~~~
skrebbel
Ahyes, smart. We didn't control the client, unfortunately, so we couldn't do
that.

(we tried to communicate with the people who did but they turned out to be the
supplier to the supplier to the customer of our customer, 5 countries away,
and fixing anything at all was _not_ high on their priority list :D)

~~~
NicoJuicy
Afterwards change the extension to .xmlok or .xmlfail (alt: zip it), no need
for vendor adjustments

------
slg
>I’ve slowly been losing faith in .NET.

That piece is interesting. I don't know many .NET developers that aren't
excited with what Microsoft has been doing with .NET over the last couple
years. Can anyone shed light on why someone would be losing faith in it?

~~~
shouldbworking
I've been a .NET developer for years but I've also been a big Java guy. The
lack of an OSS ecosystem in .NET is a huge glaring problem. This is compounded
by the echo chamber that is the MS developer world.

There have been multiple projects where lack of a library or database driver
have resulted in hacks or passing something to a little Java app and back
because it's unrealistic to do the work in C#. Like I said, the MS world seems
to be an echo chamber and the vast majority of C# devs shun any solution
outside official MS channels. Why do they do this?

Because open source devs generally still dislike MS and until .NET core (which
is not ready for prime time) using C# saddled you to Visual Studio, Windows,
SQL Server, and IIS. Because of this, the open source community on other
languages like Python or Java is maybe 20x bigger.

The other reason open source avoids the MS platform is because they like to
take your stuff and replace it with the "MS official" version. Entity
framework was originally a poor emulation of NHibernate. WebApi a copy of
Spring Boot. Instead of helping your project, or making it official like Java
tends to do, MS likes to replace your OSS with something proprietary.

The other big .NET problem is speed. I like C# syntax better, but when I wanna
get something done on my own I reach for Java first. It's faster and more
flexible. In some areas the execution speed difference is 100x. The CLR might
be quick but MS never considered performance a priority until .NET core,
because before core they were only competing with themselves.

The echo chamberyness is leaving the MS stack in the dust. Everyone else runs
on Linux now. Everyone else is using containers and SPA frameworks and
Postgres. In the MS world, the unofficial rule is that if it's not a visual
studio project template don't use it. It encourages reaching out of the
Microsoft ecosystem as little as possible.

Big sites like stackoverflow that have chosen to go with C# have blogged about
their adventures. Most of these adventures involve building things that are
already available from the community in most languages. Core may save .NET but
it might be too little too late. Windows has already lost the war for server
operating system and that leaves little reason to use C# over the primary
competitors Java and Go. Both of those have ecosystems far larger and far
better support for things like databases, mapreduce, Linux, containers, etc...

~~~
polskibus
I'm curious, in what areas is Java 100x faster than C#?

~~~
_pmf_
Aggressive inlining and devirtualization is one thing. Escape analysis that
allows objects that one would expect by all rational and technological reason
to be required to be allocated on the heap being allowed to be allocated on
the stack.

~~~
zigzigzag
It's not just a handful of optimisations. The entire JVM is performance
focused in a way the CLR just isn't. Microsoft historically put their
resources into the C# language and the IDE. Sun/Oracle put their efforts into
the runtime.

For instance, the CLR doesn't do any profile guided or speculative
optimisations at all. That's a 20% win for most Java apps and even more still
for languages with higher levels of abstraction like Scala. So right there
from the start .NET is 20% behind. The CLR doesn't have an interpreter, so, it
spends a lot of time JIT compiling code that isn't particularly important.
That takes CPU time away from your app, not sure how much of an effect that is
but I can imagine it's at least another 10% down. C# asks devs to control de-
virtualisation by hand to try and compensate, but the JVM can do a better job
automatically. CLR is only now starting to look at tiered compilation and even
then only a very basic form compared to Java which has had it since Java 8.

But not only is the base infrastructure and approach far more advanced, the
JVM's JIT compilers are way ahead of even the new RyuJIT. Not just fancy
optimisations like devirt and escape analysis/scalar replacement, but even
basic things like profile-guided basic block ordering. JVM can do auto-
vectorisation of loops, lock optimisations, it can even replace speculatively
profile and replace synchronised blocks with hardware (TSX) transactional
memory. The CLR is multiple generations behind where HotSpot is. And the JVM
team is extending its lead even further with projects like Graal.

------
ympostor
I had always wondered how he funded his work on IKVM.NET anyway. He worked on
it so tirelessly, it felt like he was a full-time employee of it.

------
garganzol
Told you so. Give a couple more years to .NET Core et al guys in reign, and
they will totally destroy .NET. J Duffy I'm looking at you.

~~~
voltagex_
What in particular is worrying you about NET Core?

~~~
kodfodrasz
I guess that the platform and tooling is pretty much in motion yet. I think
this is totally OK, it is in its early stage of life, and agile projects are
like this in that stage. This is a cost for us, as we use them, yet we accept
this, as the benefits will be larger for us, especially in the long run.

We can see how the development works, and maybe people with more enterprisey
(it here a word for this?) background find this problematic, as they are more
accustomed to the slow pace of innovation/changes in that area.

For me, with pretty much FLOSS experience (mostly as user) this is nothing new
or worrying. This is how business is done in the open, where you see
experimentation. This is the way if you want to listen to your users: show
them what you do, and listen to them. Do this often, not once every 3-5 years,
as in the enterprise.

------
j_s
IKVM was always the king of the edge cases.

I will follow anything Jeroen publishes in the future with interest!

------
maxxxxx
This is sad. IKVM should have been supported by MS a lot. Being able to use
Java libraries would be a huge help for .NET.

~~~
skrowl
As a .NET developer, I only use wrappers for unmanaged code as a last resort.
Having to introduce a dependency on something as slow and security-bug-rich as
Java would be a hard sell in most .NET shops.

~~~
MichaelGG
Can you name a few specific examples of where you are using .NET/CLR that Java
would have introduced security holes? Basically all the high profile ones that
people think of are code-loading issues, similar to XBAP and other .NET tech's
bugs. In other words, the "Java insecure" meme applies to very little actual
Java dev.

~~~
skrowl
You have to install a whole extra runtime on all of your servers, including
production internet-facing servers to use Java. If you can't see that would
add to your potential attack surface, I can't help you.

~~~
MichaelGG
Please list a few remote access vulnerabilities caused by the JVM and not app.

------
custos
This is disappointing. I've used IKVM to convert a few Java libraries written
by academics where no .NET equivalent existed at the time (NLP and some other
math libraries).

~~~
thr0waway1239
OTOH, without IKVM, there will be a lot of people who will be forced to come
out of the .NET ecosystem when using these libraries, which will end up
improving both the libraries and the surrounding ecosystem (e.g. many people
dislike Java the language, but maybe people will migrate towards Kotlin for
maintaining/improving these libraries). Also, any improvements they make can
be more easily integrated back into the source.

~~~
shouldbworking
IKVM exists because library offerings kinda suck in C#, not the other way
around. I find it more likely that people will just write these applications
in Java.

MS has a long, dark history with open source including attempting to kill both
Linux and Java. Many of us have forgiven but will never forget.

~~~
frik
They are doing something very bad with Win10 - the private data is at risk. I
know about their history, and they haven't changed. They still have a monopoly
on desktop/notebook. They just lost the mobile sector to Apple and Google -
the end consumer decided.

------
_pmf_
It's a marvelous piece of technology. You would think when importing a Java
dependency with moderately complex dependencies, there'd be some catch; there
isn't. You would expect that JNI does not work (how should it?); but it does.
You'd expect reflection support to be broken; but it works.

If the folks at Microsoft had any sense, they would have hired this guy, but
they're probably busy rewriting Office in TypeScript based on Electron.

------
PeterStuer
For me, the one thing that .NET has going for it is Visual Studio. Every time
I've tried returning to Java, it is not the language but the dev environment
that has me running away in horror.

~~~
frik
JetBrains IDEA, Eclipse and NetBeans are all pretty good and comparable IDEs.
Visual Studio has no unique selling point per se, if you are into C# its a
very good choice eecially with the Resharper plugin (some of its features got
cloned).

------
domenukk
I remember it was the only way to get Java running on the first surface RT
with ARM Windows [http://domenukk.blogspot.de/2013/05/microsoft-surface-
runnin...](http://domenukk.blogspot.de/2013/05/microsoft-surface-running-
jdownloader.html?m=1) Good times

------
ronack
Huh, I had assumed this was dead for quite some time based on the lack of
updates. Here's hoping someone will take this as an opportunity to revive the
project.

~~~
ygra
The lack of updates may have coincided with lack of updates to Java.

