Java Applets running on the .NET Framework

Brian Keller points out the newly released J# Browser Controls 1.1b beta.  If you have the source code for a Java applet, you can use the J# browser controls and have your code running on the .NET Framework in a couple of minutes.  This is pretty powerful stuff, and a great way to reuse your existing Java assets. 

By the clock on the wall, it looks like its time to dust off all those “great” technology showcase applets like Snake and Asternoid that showed the true power of the web and convert them to run on the .NET Framework. 


Comments (4)

  1. Kevin Daly says:

    This brings up a somewhat sensitive issue…we found a while ago that any Windows Forms control we had embedded in a web page consistently added around 20 megs to the memory footprint for IE – as if IE were hosting the whole runtime in-process or something weird like that (we don’t get the same effect with smart clients, thank God. Or possibly thank ieexec).

    I’m sure there’s something obvious and avoidable we’re missing there, but for now I’m regretfully not quite able to get enthusiastic about the idea of Java applets converted to .NET (not that I have a huge amount of enthusiasm for Java applets…too many cases of Annoying Grey Box or "Ooh, Wobbly Text, How Nice").

  2. Hey Kevin,

    Interesting behavior, I tried to replicate what you were seeing, and I didn’t notice a difference between Internet Explorer with a Windows Form control and IE by itself. The total memory was on average 25 mb for IE with or without the hosted control. Just to clarify, you would be getting an *additional* 20mb memory when viewing a page with a hosted Windows Form, meaning 45mb? I’ve forwarded your comment internally and I’ll see if there is a known issue with this that maybe I don’t know about.



  3. Kevin Daly says:

    Thanks Dan.

    Yep, that’s an additional 20mb (give or take a mb). It’s independent of what the hosted control is (we found it in one that did virtually nothing, and then went back and checked others written months before, and I wrote a further one to test…all showed the same behaviour, including on different machines.

    I was puzzled that I could find any references to the problem online (since it doesn’t take much to get people whining.I should probably mention that we’re running 1.0 SP 2 (if this is something that goes away in 1.1 I’d be delighted because I’m trying to make the case for the upgrade). I assume that it’s caused by some odd feature of our configuration, but I’m not sure what it could be, since it occurs on locked-down machines, policy managed desktops, and developer machines, all of which are configured quite differently. It’s a puzzle.

    PS. I’m sorry about the largely off-topic rant.

    PPS. Silver lining: We first discovered the problem because some users on our network were getting serious performance degradation – these ones only had 128mb of RAM, when they were all supposed to have at least 256mb. So it acted as a kind of software "barium meal" to help us find all the dodgy machines.