 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / Visual J# / March 2004Can you keep code in Java and compile for J# Browser Controls?
We have a huge Java applet developed in Visual J++, using no features beyond Java 1.1.4 and no Microsoft-specific features. The applet runs on a variety of Java platforms on Windows and Macintosh; the user gets a CAB file or a JAR file depending on the browser and Java configuration. We'd be glad to compile the code to support the J# Browser Controls environment if we could keep our code in Java and compile for this new environment every time we also publish new CAB and JAR files (a few times a week). Would preparing our code for J# Browser Controls require changes in the code that would make it not work for other Java environments? Or is it just a matter of hitting another compile button and getting a different export format to support J# Browser Controls? DejaVu =:o) Please watch Brians Video, and try the compile button. =:o) http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20031114jsharpbk/m anifest.xml http://msdn.microsoft.com/vjsharp/downloads/browsercontrols/ http://msdn.microsoft.com/library/en-us/dv_vstechart/html/vjtskMigratingJavaAppl etsToMicrosoftJBrowserControls.asp  SignatureRegards, Lars-Inge Tonnessen http://emailme.larsinge.com http://www.larsinge.com > DejaVu =:o) > Please watch Brians Video, and try the compile button. =:o) The video was very helpful; the other two links I had already found. I have some follow-up questions: 1. There was an allusion to some parts of a VJ++ program not converting. Is there some list of things that don't convert? I see from: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/ht ml/vjtskMigratingJavaAppletsToMicrosoftJBrowserControls.asp that there are problems passing parameters. Are there other ways of inputting parameter-like information such as strings to the program such as the name of the data module to use or the input information to enter automatically? I see from: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/ht ml/vjtchsecuritysemanticsforjbrowsercontrols.asp that it can be difficult to get security clearance for writing files, but it is not clear if this applies to other methods needing security clearance with the regular Java approach such as URLConnection getOutputStream(). Is there a more detailed list somewhere? 2. If the Java Language Conversion Assistant: http://msdn.microsoft.com/vstudio/downloads/tools/jlca/ is used for an applet, does the user need any non-generic parts of Internet Explorer or Windows? How broad is the installed base for the J# Browser Controls runtime and will it become more standard? Are there differences in the success or ease of the conversion process using the JLCA approach versus the J# Browser Controls approach? >>DejaVu =:o) >>Please watch Brians Video, and try the compile button. =:o) [quoted text clipped - 25 lines] > the success or ease of the conversion process using the JLCA approach versus > the J# Browser Controls approach? I guess what I am trying to figure out with J# Browser controls, it that it is provided by MS, but they don't seem to be pushing users to install it... I don't see little buttons on websites encouraging its download, like you see for other plug-ins (quicktime, flash, java). Can anybody point me to a single mainstream website that is asking me as a user to install J# browser control so that I can run their applet? So I get the impression it is for developers who wrote applets that need the ms jvm and used microsoft-specific classes - something of course mentioned in the video. What benefit it provides developers/users of standard applets I do not yet see. You mention that some of your users have J# Browser controls installed - because of the "awareness" issue I mention above, I have a hard time believing anyone other than a developer would have found it, downloaded it, and installed it. Please correct me if I'm wrong here, I really would like to get a better grasp on this too... exactly, how broad is the installed base? Is MS trying to get this on every computer the way they are/will with .net? If so, I would imagine that J# runtime and J# browser controls would be shipped integrated with the next version of .net. does anybody know of any such plans? --snip > So I get the impression it is for developers who wrote applets that need > the ms jvm and used microsoft-specific classes - something of course [quoted text clipped - 9 lines] > integrated with the next version of .net. does anybody know of any such > plans? I don't think MS would want to bloat the (growing) .NET Framework install any further with J# Redistributable and J# Browser control, so I doubt that J# and related integration will happen any time soon. - Mitch Gallant > I don't think MS would want to bloat the (growing) .NET Framework install > any further with J# Redistributable and J# Browser control, so I doubt that > J# and related integration will happen any time soon. > > - Mitch Gallant I think you are probably right... but what that means is, no surprise, but unfortunately, that J# is a second-class citizen in the world of C++.net, C#.net, VB.Net. While it is first-class in it's ability to use the .net framework, your/our users are always going to need extra installs, and wonder why. > > I don't think MS would want to bloat the (growing) .NET Framework install > > any further with J# Redistributable and J# Browser control, so I doubt that > > J# and related integration will happen any time soon. I've been told otherwise, that it will be merged eventually with the main .NET framework distribution (not ported/packed with the Compact .NET framework yet unfortunately, but who knows in the future) It wasn't merged in the last .NET framework version cause J# wasn't ready yet. Similar goes for the J# Browser Controls. Till recently the browser controls were in beta etc. Lets waits to see what happens with the .NET2.0 distribution ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ George Birbilis <birbilis@kagi.com> [MVP J#] [9880] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + QuickTime VCL and ActiveX controls (for PowerPoint/VB/Delphi etc.) + Plugs VCL and ActiveX controls (InterProcess/Internet communication) + TransFormations, VB6 forms to ASP.net WebForms convertion http://www.kagi.com/birbilis + Robotics http://www.mech.upatras.gr/~robgroup ........................................................................ There are no current plans to merge the J# runtime into the .Net Runtime. Thanks, Michael Green Microsoft Developer Support If I don't remember this wrong, I think I read in a newsgroup it will be included as default in future releases of Windows (eg. Longhorn) and the .Net platform. I don't have a reference, so don't quote me on it. Maybe Michael Green knows anything about this? SignatureRegards, Lars-Inge Tonnessen http://emailme.larsinge.com http://www.larsinge.com I was incorrect when I stated that. There are no current plans to include the J# Browser control library or the J# runtime with the .Net Runtime. They will be separate installs. Thanks, Michael Green Microsoft Developer Support -------------------- | Reply-To: "Lars-Inge T?nnessen" <http://emailme.larsinge.com> | From: "Lars-Inge T?nnessen" <http://emailme.larsinge.com> | References: <eNV#PU42DHA.3140@tk2msftngp13.phx.gbl> <OfJVaz42DHA.2032@TK2MSFTNGP09.phx.gbl> <uLLzX152DHA.2952@TK2MSFTNGP09.phx.gbl> <bu6r2a$c4m$00$1@news.t-online.com> <uSXZNK62DHA.2032@TK2MSFTNGP09.phx.gbl> | Subject: Ping Michael Green... | Date: Thu, 15 Jan 2004 23:25:10 +0100 [quoted text clipped - 15 lines] | | Maybe Michael Green knows anything about this? So the J# browser control doesn't include the J# runtime and vice-versa? So is it correct that if someone wants to run a J# browser control, they need 3 separate downloads/installs (assuming they don't have any of them): 1. .net runtime 2. J# runtime 3. J# browser controls Ken > I was incorrect when I stated that. There are no current plans to include > the J# Browser control library or the J# runtime with the .Net Runtime. [quoted text clipped - 31 lines] > | > | Maybe Michael Green knows anything about this? > So the J# browser control doesn't include the J# runtime and vice-versa? Don't think so. Take a look at the file sizes: Microsoft J# Browser Controls Version 1.1 1672 KB Microsoft Visual J# .NET Version 1.1 Redistributable Package 6765 KB Microsoft .NET Framework Version 1.1 Redistributable Package 23698 KB > So is it correct that if someone wants to run a J# browser control, they > need 3 separate downloads/installs (assuming they don't have any of them): > 1. .net runtime > 2. J# runtime > 3. J# browser controls Yes, that is correct. That is why I don't use it in public. I can't assume normal peoples have installed all that. I think it's even pretty much to assume they have the normal .net framework installed. SignatureRegards, Lars-Inge Tonnessen http://emailme.larsinge.com http://www.larsinge.com Hi Ken, You are correct. If someone wants to run a J# Browser control they will need to download: 1) The .Net Runtime 2) The J# Runtime 3) The J# Browser Controls Runtime. Thanks, Michael Green Microsoft Developer Support -------------------- | From: Ken Larson <kendotlarson@mindspring.com> | Newsgroups: microsoft.public.dotnet.vjsharp [quoted text clipped - 4 lines] | Message-ID: <buhkih$th1$04$1@news.t-online.com> | References: <eNV#PU42DHA.3140@tk2msftngp13.phx.gbl> <OfJVaz42DHA.2032@TK2MSFTNGP09.phx.gbl> <uLLzX152DHA.2952@TK2MSFTNGP09.phx.gbl> <bu6r2a$c4m$00$1@news.t-online.com> <uSXZNK62DHA.2032@TK2MSFTNGP09.phx.gbl> <O9y1wZ72DHA.1652@TK2MSFTNGP11.phx.gbl> <#Ytceet3DHA.3348@cpmsftngxa07.phx.gbl> | Mime-Version: 1.0 | Content-Type: text/plain; charset=ISO-8859-1; format=flowed | Content-Transfer-Encoding: 8bit | X-Trace: news.t-online.com 1074550162 04 30241 SRwQGIPJnyEpbA0 040119 22:09:22 | X-Complaints-To: usenet-abuse@t-online.de | X-ID: SAoiweZSweidTBrJkHLjaY8KQEmV9Xh4jHYeLZODmnDNROWhOE1Lcq | User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 | X-Accept-Language: en-us, en | In-Reply-To: <#Ytceet3DHA.3348@cpmsftngxa07.phx.gbl> | Path: cpmsftngxa07.phx.gbl!cpmsftngxa10.phx.gbl!TK2MSFTNGXA05.phx.gbl!TK2MSFTNGP08 .phx.gbl!newsfeed00.sul.t-online.de!newsmm00.sul.t-online.com!t-online.de!ne ws.t-online.com!not-for-mail | Xref: cpmsftngxa07.phx.gbl microsoft.public.dotnet.vjsharp:5205 | X-Tomcat-NG: microsoft.public.dotnet.vjsharp [quoted text clipped - 44 lines] | > | | > | Maybe Michael Green knows anything about this? > What benefit it provides developers/users of > standard applets I do not yet see. You mention that some of your users > have J# Browser controls installed - because of the "awareness" issue I > mention above, I have a hard time believing anyone other than a > developer would have found it, downloaded it, and installed it. I haven't heard of anyone having J# Browser Controls in the wild; I'm just trying to anticipate possible demand for this functionality. Since the Microsoft JVM is disappearing I am interested in supporting users who: 1. Don't have the Sun JVM and thus are unable run any official Java, or 2. Have the Sun JVM but would prefer a technology that works better if support for it is already installed (the Microsoft JVM works much better than the Sun JVM so one might expect that Microsoft's Java migration functionality would keep up this tradition). Typically our users are prohibited from installing such downloads by their network policies or reluctant to do so. As a result, just depending on the Sun JVM is not ideal. How about the WinForms controls generated by the Java Language Conversion Assistant? Are there any downloads beyond a generic Windows XT and Internet Explorer needed to run these? >>What benefit it provides developers/users of >>standard applets I do not yet see. You mention that some of your users [quoted text clipped - 18 lines] > Assistant? Are there any downloads beyond a generic Windows XT and Internet > Explorer needed to run these? I would probably recommend that anyone in a controlled corporate/intranet environment who wants an ms-only "applet" to use a C# user control using win forms, rather than J# browser applets. I can believe MS JVM runs faster than Sun, although I'm not sure about that with the latest from sun, but that's beside the point. you should check out the benchmarks that were recently done comparing J# with C# and Java (and some others). It found, and I have found myself that for certain things J# is pretty slow. I am pretty sure that J# will always be the slower bastard child of C# and Java... So if you want performance, I would stick with Sun Java or go straight to C#. So in short, 1. may be a valid reason, but I'd be wary of 2. -- snip > I would probably recommend that anyone in a controlled > corporate/intranet environment who wants an ms-only "applet" to use a C# > user control using win forms, rather than J# browser applets. I agree, if you are embarking on a new project > I can believe MS JVM runs faster than Sun, although I'm not sure about > that with the latest from sun, but that's beside the point: Some very simple fp multiply shows that .NET and Sun JVM are about the same: http://pages.istar.ca/~neutron/benchfloat Interesting that the most recent (and probably final) MS JVM is slower than it used to be! J# can do things that the first-rate .NET languages can't, such as BigInteger arithmetic (of course that is a legacy Java 1.1.4 classes :-) - Mitch Gallant MVP Security http://pages.istar.ca/~neutron > -- snip > [quoted text clipped - 18 lines] > MVP Security > http://pages.istar.ca/~neutron Check this out: http://osnews.com/story.php?news_id=5602 showed that mainly the I/O performance was hurting. If you're not doing much of that, then it might not matter. Your tests appear to be comparing C# to Java, which I would agree would both have good/comparable performance. The interesting thing about the link I posted is that J# and C# have very different performance... > showed that mainly the I/O performance was hurting. Someone have a job to do here... =:o) SignatureRegards, Lars-Inge Tonnessen http://emailme.larsinge.com http://www.larsinge.com > I would probably recommend that anyone in a controlled > corporate/intranet environment who wants an ms-only "applet" to use a C# > user control using win forms, rather than J# browser applets. Comparing generating win forms from Java code versus using J# browser controls: 1. Is the procedure for generating win forms as simple? 2. Is the ability to support the feature set of pure Java 1.1.4 code as good? > I can believe MS JVM runs faster than Sun, although I'm not sure about > that with the latest from sun, but that's beside the point. you should > check out the benchmarks that were recently done comparing J# with C# > and Java (and some others). For arithmetical calculations the Sun JVM caught up to the Microsoft JVM long ago. But for GUI display the difference is huge. It has always been difficult to do good benchmarks of GUI display, but the difference is very much in Microsoft's favor. Also, the Sun JRE does not use Windows fonts, so text looks terrible, at least for Java 1.1 programs. We do our demos using the Microsoft JVM unless someone asks for another environment. The Macintosh version is tempting with its brush metal background for Frames, once Apple makes some progress fixing all the bugs. >>I would probably recommend that anyone in a controlled >>corporate/intranet environment who wants an ms-only "applet" to use a C# [quoted text clipped - 3 lines] > controls: > 1. Is the procedure for generating win forms as simple? I guess it depends on what you are used to. To be honest, I don't work much with applets, but I have developed several GUI apps using WFC in J++ and Winforms in J#.Net, I find both quite simple. > 2. Is the ability to support the feature set of pure Java 1.1.4 code as > good? Not sure what you mean here, if you are doing win forms in J#, or using J# browser controls, both are J# and have access to the same J# version of the java api, I think with the exception of the applet stuff itself in J# browser controls. But I assume if you were writing something using J# and win forms, the result would be a form or a user control, not an applet. Note that it is possible to run a user control in a web browser (IE with .net installed). >>I can believe MS JVM runs faster than Sun, although I'm not sure about >>that with the latest from sun, but that's beside the point. you should [quoted text clipped - 6 lines] > much in Microsoft's favor. Also, the Sun JRE does not use Windows fonts, so > text looks terrible, at least for Java 1.1 programs. I'd be curious if someone has any benchmark results (formal or informal) comparing a J# applet using browser controls with both of these. > We do our demos using the Microsoft JVM unless someone asks for another > environment. The Macintosh version is tempting with its brush metal > background for Frames, once Apple makes some progress fixing all the bugs. > We have a huge Java applet developed in Visual J++, using no features beyond > Java 1.1.4 and no Microsoft-specific features. The applet runs on a variety [quoted text clipped - 8 lines] > just a matter of hitting another compile button and getting a different > export format to support J# Browser Controls? curious, if it uses no ms-specific features, what is the reason for using J#/J# Browser control? > curious, if it uses no ms-specific features, what is the reason for > using J#/J# Browser control? We try to support the platforms the users have available and prefer. If they have the J# Browser Control runtime and not a Java VM it would be good to support that. At the moment there are probably few users in that situation. In the longer term, if the J# Browser Control environment is common and if it has a performance and appearance advantage over Sun Java similar to that of the Microsoft Java VM over Sun Java VM, it would be good to give users the opportunity to use the better environment. Mickey, This has grown to a pretty large thread, but I wanted to post something of a summary. Please keep in mind that J# was designed to be used to migrate away from Java. In otherwords it was not designed so you can have a single code base and compile it with various Java and J# compilers. That being said, if you stick to the supported JDK (1.1.4) you should be able to keep a common codebase. The problem with that is you won't be able to take advantage of the .Net class libraries or later Java class libs (> JDK 1.1.4). So you are basically stuck with the worst of both worlds (which may not be a problem for you). You won't be able to take advantage of the newer Java technologies nor the newer .Net technologies. Thanks, Michael Green Microsoft Developer Support -------------------- | From: "Mickey Segal" <ignored@example.com> | Subject: Can you keep code in Java and compile for J# Browser Controls? [quoted text clipped - 7 lines] | Newsgroups: microsoft.public.dotnet.vjsharp | NNTP-Posting-Host: 146-115-41-176.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com 146.115.41.176 | Path: cpmsftngxa07.phx.gbl!cpmsftngxa10.phx.gbl!TK2MSFTNGXA05.phx.gbl!TK2MSFTNGP08 .phx.gbl!tk2msftngp13.phx.gbl | Xref: cpmsftngxa07.phx.gbl microsoft.public.dotnet.vjsharp:5169 | X-Tomcat-NG: microsoft.public.dotnet.vjsharp [quoted text clipped - 11 lines] | just a matter of hitting another compile button and getting a different | export format to support J# Browser Controls? Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.