J# 337
fuze writes: "It's basically a way for Java developers to migrate their Java apps to .NET.... even provide a 'convenient' migration tool... check it out on MSDN." News.com has a story describing Microsoft's plans to suck Java into .Net, and some commentary saying basically, "No one will use it".
Of course "no one" will use it (Score:4, Insightful)
Maybe I missed the point, but it's a migration tool. It's not meant to take the place of Java, or even really compete with Java, other than it makes it possible for developers to take their existing java code and move it to the .NET platform with relatively few changes. This means the old objects are now accessible to all .NET languages (C#, VB, Managed-C++, and all the other marginal languages that have been ported), making it less painful to move over to C#. Until the old modules are reimplemented, they're still available. Moreover, even non-.NET languages will have access to those objects as COM objects, since that's a benefit of the CLR. So if you want to write code in C, or non-managed C++, you can still get at those objects (which you couldn't do before without extra work).
Re:Of course "no one" will use it (Score:5, Interesting)
So basically it is a migration tool for J++ applications. Considering that is a MS product, it makes you wonder if this is the best MS can pull of after all the sole reason migration is needed is because MS decided to drop Java support (so they already screwed you once).
And even for J++ it is limited since it only allows you to compile source code, you lose information stored in e.g. forms, project files and so on. In addition, Java objects tend to be closesely tied to the Java API and reusing them basically means you are using the Java. So you might as well go for the real thing (including richer API, better performance and so on) and use the com bridge to communicate with the objects.
In any case, if this is just a migration tool, MS is going through a hell of a lot of trouble to present it as a Java alternative.
Some advise to people considering to use it:
- After 'migration' it is still Java code you are using. It won't be much faster and you will still have to maintain it.
- MS is not very Java friendly, they might drop support for the migration tool at their convenience. The long term strategy is C# (if it ever takes of), not J#.
- Migration to real Java is probably much easier unless you heavily rely on MS specific APIs
- There are ways of letting Java objects talk to COM objects (and consequently also
Re:Of course "no one" will use it (Score:4, Insightful)
Where and how has MSFT presented this as anything more than a migration tool? From the MSDN Visual J# page [microsoft.com].
This is rather unfortunate since it looks like no one is working on a port of the Java language to
Re:Get thee to the C# decompiler. (Score:3)
Whether you compile to
It is worthwhile to mention that J# is not really a migration tool since there is no conversion of source code taking place into one of the typical
jdk1.0.2 code still compiles on jdk1.4 (ok, minus some minor API changes which were necessary and are generally easy to fix). The resulting bytecode can still be executed on a jdk1.0.2 VM. Try to do that with VB applications written in 1995 (when jdk1.0.2 was released) on the latest version of VB and you will see my point.
Evil Ploy Alert! (Score:5, Funny)
1. GNU#.net (RMS finally gave up and was hired my MS)
2. OSX.net (Steve jobs has now finally ground his teeth all the way off)
3.
Well (Score:3, Interesting)
Re:Well (Score:5, Insightful)
Uhh, hello? Didn't Sun just sue Microsoft? Aren't a bunch of other companies, including AOL and Real arguing with MS right now over bundling of products? It's not as if MS are saying that you can't run Java, they're just saying that it's a piece of third party software, you have to install it yourself, just like you have to install, say, WinAmp if you want it, or Photoshop.
Sorry, but I think Microsoft are doing the right thing here, or at least they are doing the least-worst thing.
Isn't it all supposed to be about choice? A world where Java is the only language (and we all know how responsive Sun have been to the wishes of the community, can you say ECMA standard?) would be a poorer world than one where Java/J2EE and C#/.NET have to compete on features and quality.
There's one way out of this for the Anti-Microsoft camp: get Java to be like C, SQL and FORTRAN, an ANSI standard. Until we see that, this battle isn't one for the engineers, it's marketeer vs marketeer.
Re:Well (Score:2, Insightful)
Have you seen the commentary arguing that this, BTW, is a good thing for Java? It avoids having to write for an outdated version, as people will get the latest version when (if) they install the VM.
/Janne
Re:Well (Score:2, Informative)
I had a JVM installeed for a while recently, as I tried to run a roleplaying accessory (pcgen) written in Java, but it was just far too slow to be useful, so I removed the stuff again.
/Janne
What's next? (Score:2, Funny)
Boycott D Flat (Score:3, Funny)
According to CNN, Microsoft's B flat is the programming language of choice of Osama bin Laden.
GTK# (Score:4, Informative)
Hello World in C# using the GTK toolkit [go-mono.com]
The syntax does look pretty clean.
It's not quite up to Java GNOME [sourceforge.net] functionality yet, which is now compilable to native binaries, with gcc3 (For those of us who couldn't care less about platform independence but really like Java as a modern language). More choice is always good however.
Re:GTK# (Score:5, Funny)
Corporate Thinking or Public Service? (Score:2, Insightful)
- your grip on the server market appears to be slipping
- great companies such as google.com are proving that you can grab web market share fairly quickly with a better product
- technologies such as Linux, VM Ware, WINE and Java are threatening to nibble away your desktop market
- having some spectacular white elephants such as MSN on record
I ask the question
a) play to your strength and leverage your current market domination and try to eliminate competing standards while creating new "standards", eg
b)go open source, support Java, employ open standards, go cross platform, etc etc and risk losing any market dominance you have now?
This is a tricky question but throws open the debate for us rabid slashdotters
Dr. Simon Ronald
Nerdy SpeedReading Software http://www.rocketreader.com (shameless ad)
Re:Corporate Thinking or Public Service? (Score:3, Insightful)
Most of the people that would ever run these would be running *nix/*bsd already. In fact you need to one a copy of Windows for VMware, and it prolly helps for Wine.
And besides, as long as people are running windows apps, developers will continue to target windows. This is similar to the dilemna IBM faced with OS/2 Win32 emu stuff. It was so good (ANY win3.1 app could run in native OS/2) that very few native OS/2 apps were ever made.
Scott
Re:Corporate Thinking or Public Service? (Score:5, Insightful)
a) play to your strength and leverage your current market domination and try to eliminate competing standards while creating new "standards", eg
b)go open source, support Java, employ open standards, go cross platform, etc etc and risk losing any market dominance you have now?
Legally, you would have no choice at all. If a director fails to act in the interest of shareholders, the penalty can be a jail sentence and a ban from ever running a company again, at least under UK law. Yes, that's right, you can go to jail for doing the "right thing". Unless you could prove that it was in the best interest of shareholders - who will tear you apart if you miss your quarterly earnings target - there is no option for you but (a).
The reason corporations put profit before everything else is because the law - created by the governments, who represent the taxpayer - have decreed that they must do so. It would be a little hypocritical to criticize a thing for acting in accordance with its nature.
The reason corporations put profit before ... (Score:2)
Actually profits does NOT come before everything else - market valuation comes first ...
Re:Corporate Thinking or Public Service? (Score:5, Insightful)
Well, I understand that as a self-described "rabid Slashdotter," this might be news to you, but your entire premise is pretty wacked.
- your grip on the server market appears to be slipping
Hate to break it to you, but Microsoft's server market share has never gone down since NT first came out.
great companies such as google.com are proving that you can grab web market share fairly quickly with a better product
Well, seeing how Microsoft/MSN gets around 7 times the number of unique visitors that Google gets, and that they hang around the site around 25 times longer than Google's, you tell me how concerned they are.
technologies such as Linux, VM Ware, WINE and Java are threatening to nibble away your desktop market
They are? Funny that Microsoft's desktop market share, just like its server market share, went up over the past year. Guess they better be on the lookout for OS/2 and Amiga, too.
having some spectacular white elephants such as MSN on record
See above about MSN.
I think that the shareholders of Microsoft would be pretty relieved that it's one of the best performing stocks this year. Oh, and they're probably happy as Hell that they don't listen to Slashdot hype, otherwise they might've traded all their Microsoft shares for stock in VA Linux, Red Hat, and Sun, thus watching their kids' college funds go *poof*!
Re:Corporate Thinking or Public Service? (Score:5, Funny)
considering that google is a search engine , and msn is just a mess, I would consider your statement to be a glowing endorsement of google. People get what they need 5 times faster!.
And it's true because you said it!.
Re:Corporate Thinking or Public Service? (Score:2)
Re:Corporate Thinking or Public Service? (Score:2)
This is good news... (Score:3, Interesting)
The ability to write in your favorite language C#, C++, VB, JScript, etc and now Java is a huge improvement over locking a project into one language only and missing out on all the other shared libraries because your project is in Java or Objective-C or Python etc.
Unfortunately in removing one lock, microsoft has added another (to their OS). What I'd love to see is a Common Runtime for Linux... unfortunately all I see is people dismissing it or complaining because its Microsoft.
Re:This is good news... (Score:5, Insightful)
I'll admit that I have never done any large scale programming, but this statement about language lock-in seems entirely false to me. I have done programming for research purposes and combined C with C++, C with Scheme, and used tools mostly written in C call Fortran libraries. I have seen and used examples of Perl and Python programs accessing common C libraries.
Where is the lock-in?
Re:This is good news... (Score:3, Insightful)
Sure they say they can build a CLR for other platforms, but I'll believe it when I see it.
Of course, if they didn't have this CLR, then they couldn't make the claim that they were going multi-platform so it looks like they just found a way to slow down your Windows code for no good reason.
Re:This is good news... (Score:4, Interesting)
For now, yes, the .NET framework is only available for Windows. However, Microsoft has committed to providing a reference implementation for the *BSDs (FreeBSD, I believe), and other projects like Mono have sprung up to bring an implementation to Linux and other unix-like operating systems. Since Microsoft has submitted both the CLR and C# to ECMA for standardization (say what you will about ECMA, but at least it's a standards body), anybody can write their own implementation. Sun's backed out several times on submitting Java to ECMA.
That would be true, if it were the case that CLR bytecode only ran under the VM. However, that's not the case at all. The CLR has the ability to compile its bytecode down to native code for whatever machine you're on. Most likely the way this will happen is that CLR bytecode will be "shipped" (in a box, or as a download), and as part of the installation that bytecode will get compiled to your platform. What that means is that, taking a Windows-only view for a moment, when you buy Office.NET (just as an example -- I don't know whether Office.NET will be targetting the CLR or not), it won't matter whether you're running on a 32-bit x86-based system, or on a 64-bit iTanium (or whatever AMD's 64-bit chip is called), the same version will run on both. And with native speed, because after installation, you'll be running native code. Obviously, it's developer choice whether or not to compile down to native code, but that's the point -- the choice exists. And given full CLR implementations on other platforms, I don't see any reason why pure CLR bytecode wouldn't be perfectly cross platform, even to the point of compiling down to native code and running as a native app on your chosen system. Perhaps this is how we'll eventually see IE, Office, etc on Linux? (Through the efforts of Mono)
Re:You really need to stop smoking that cheap shit (Score:2)
Re:You really need to stop smoking that cheap shit (Score:2, Informative)
Re:This is good news... (Score:3, Interesting)
.NET is so far as I can tell something good... Microsoft has done something right. Don't mock it, it does happen sometimes! I just can't stop feeling nervous...
I'm a Python advocate, and I like the
MS is not oficially giving up on COM, but
Re:This is good news... (Score:2)
But these things really aren't the bst part of .NET, sure having multiple languages is nice, but personally I wouldn't touch VB with a 10' barge pole. The real benifit lies in the libraries and OS integration: ADO.NET (traditional/XML data access), ASP.NET (WebForms, Web Services), WinForms (GDI+), etc... that are great improvements whatever language you choose.
Re:This is good news... (Score:2)
sure, Managed C++ doesn't support templates or multiple inheritance (because CIL doesn't support them yet), but otherwise it's C++.
Re:This is good news... (Score:2)
sure, bridges like the one you describe are nice (Microsoft's extensions to Java did exactly this with COM), but they often have limitations (for example, how do you marshal a block of memory allocated using malloc() into the Java world, or a (void*)?). The nice thing about .NET is that it provides a programming environment where such things are unnecessary: the types in one language are the same as the types in another, only the syntax is different.
question: with the bridge that you describe, is it possible to write a class in ObjC, then derive from that class in Java?
Initial reactions (Score:5, Informative)
Microsoft are still strongly implying (at least) that Visual J++ is Java. Uh, wait, didn't a court tell you to stop doing that?
Tsk, tsk, Bill. There's no "other" in that sentence.
The focus seems to be on J++ developers, not Java developers. But personally, I will use J# iff:
Basically, I can live with loading J# and hitting compile once for each of my Java projects. If it's any more hassle than that, I agree, it's not worth my while.
However, I'm keeping an open mind. Microsoft's decision to not include a JVM in WinXP concerns me, as does the increasing size of the Sun VM. I love Java and want to keep using it purely, but I'm not going to cut off my nose to spite my face. If Microsoft and Sun collude to make it hard to use Java and easy to use J#, I could be swayed. I hope not though.
Re:Initial reactions (Score:2, Informative)
scott
Re:Initial reactions (Score:4, Funny)
It compiles Java completely and correctly.
It compiles to a native .NET executable that gives a significant speed advantage over VM bytecode on a .NET platform.
I have to make exactly zero changes to my Java to have it compile to both VM bytecodes and to a .NET executable.
So basically what you're saying is that there's no way in hell you're going to use J#?
I agree with the points you made 100% but I don't think its' going to happen.
Re:Initial reactions (Score:2)
Not necessarily. Microsoft Visual J++ can be set up to disable Microsoft extensions and to use the latest JDK. It's perfectly capable of turning well formed Java into well formed bytecode. There's no point to using it, other than for the swooshy IDE, but it's usable for actual Java development.
So if J# compiles well formed Java into a fast executable, I'll consider using it. I won't like it, but I write games software, and my biggest market is Windoze. If J# gives me even a 10% speed boost at the cost of having two compiles/downloads (bytecode and .NET executable) from a single source then it might be worth my while.
Re:Initial reactions (Score:3, Informative)
Actually, the is an other. They are only referring to the java language, not the java platform. Like has been done for a large number of other languages, the
Basically, instead of compiling to java bytecode and running in a JVM, it will compile to IL and run on the CLR.
If you want cross platform support, this sucks. However, if you want to take your java app and get the best bang for your buck on the windows platform, using the CLR will probably provide better performance than a JVM, because the writer of the OS writes the CLR.
So, even if you don't currently develop with Visual J++, if you're going to release a java app for Windows.Net, you might want to think about using the MS compiler, if not the IDE.
Re:Initial reactions (Score:2)
Microsoft Visual J++ is not Java [javafaq.nu]. Admittedly, the main focus on the Sun court case was about the Microsoft JVM (now just the Virtual Machine), but Visual J++ was also panned as being a deliberate attempt to hijack Java by adding extensions.
Sure, Visual J++ does compile Java source to perfectly valid bytecode, and if J# compiles Java source to a decent executable, I'll use that. But if it extends the language, or is less than 100% capable of compiling well formed Java, then I won't call it a a Java compiler, any more than I call Visual J++ a Java compiler, or Microsoft Visual C++ a C++ compiler.
Re:Initial reactions (Score:3, Informative)
This seems a reasonable point to attach the following question, to which I cannot come up with a reasonmable answer right now...
How can it be evil for MS to INCLUDE a browser / media player / etc in XP, viciously anticompetitive and so forth,
and...
simultaneously evil for MS to EXCLUDE a JVM in XP?
If anyone can supply a reasonably coherent answer to this, I'd be really pleased to see it
TomV
Re:Initial reactions (Score:5, Interesting)
and...
simultaneously evil for MS to EXCLUDE a JVM in XP?
Actually, there's a pretty simple answer to this. Both of these actions kill competition.
Microsoft owns the browser, media player, etc that it bundles with XP, so they can eliminate competition by including them and making them impossible or extremely difficult to remove. The problem is that most people will not know enough or be motivated enough to switch to a competing product. So, since Microsoft owns the OS, they can be reasonably certain that people will use their integrated browser, media player, etc. By doing this, they can also be reasonably certain that companies who develop content for these products will be inclined to purchase Microsoft products to aid in the development of that content.
Java is a slightly different story. Microsoft does not own the Java technology. They have to play ball with Sun in order to use it. They have to follow Sun's rules. But more importantly, there is quite a bit of competition for Java development environments. Supplying a JDK or JVM with their OS does not in any way motivate developers to use their development environment, unless they can add proprietary extensions or other changes to the language to make their development products attractive. They attempted this with J++ and have been told they can't. So, since they can't make any money from J++, they decide to develop their own environments and languages, and bundle THOSE with their OS instead of Java. That effectively kills competition by sending a message to developers: "Do you want your application to run without hassle on 95% of desktop systems? Use .NET."
Try and remember that these tactics are only questionable because Microsoft has a MONOPOLY. That is the defining factor. Otherwise, they'd be considered good business practices. If Microsoft had only 30% of the desktop market, bundling the browser, media player, .NET technology and other things with XP would only help them to be certain that most of that 30% would be using their technology and their tools. They would be forced to make their tools operate on other desktop environments in order to increase market share. This would put them on an even playing field with their competitors. However, since they currently dominate the desktop market, the game is way too easy for them. Tricks like inclusion / exclusion just help cement their monopoly in other areas of the market. It is illegal to use a monopoly in one market segment to stifle competition and increase market share in other segments. Both of these tricks accomplish this. You really have to look at the end results.
Re:Initial reactions (Score:4, Insightful)
Obviously if Microsoft includes a JVM, then no users will go out and bother to download the JVM from Sun, IBM or Acme Computing. You already state that there is quite a bit of competition in the Java market, so obviously with Microsoft including this old outdated JVM it stifles the ability for that market to move forward.
I'm sorry, but the original poster was correct. Your argument is horribly inconsistent and flawed. If it is evil for Microsoft to include Internet Explorer, it is equally as evil to include a JVM.
You really can't have it both ways. If you get to say what goes in Microsoft's products, then I feel it is my moral duty to say what goes into Linux distributions.
And I hereby declare that bundling lilo into RedHat is evil because it kills competition in the boot manager market. RedHat's purpose is obviously to damage the market that System Commander operates within, without providing them adequate compensation.
Re:Initial reactions (Score:2)
Yes you can. In each case of either including or excluding something, the purpose is to be anticompetitive and maintain a monopoly.
Doing things to maintain a monopoly is illegal in the US. And in this case, "illegal", means evil.
MS is acting in a consistent and evil way. Just because in one case they are "including", and in another case they are "excluding", doesn't mean they are acting in contradictory ways, and therefore, one action must be good and the other bad. In both cases (include and exclude) the action is bad, because the action isn't really "including" or "excluding", but the action is "monopoly maintenance".
s/include/monopoly maintenance/
s/exclude/monopoly maintenance/
Re:Initial reactions (Score:2)
Hint: Microsofts exclusion of the JVM was obviously done for technical reasons. i.e. they are deprecating that code because it is no longer actively maintained. It's an optional download now, but with the next release of Windows I can guarantee you there won't be a download at all.
That decision to not maintain the code was not made by Microsoft, but rather Sun. So you are really claiming that Sun is attempting to maintain Microsoft's monopoly. Which really doesn't make any sense at all.
Sounds to me like this issue is much more complicated than good versus evil. Maybe you should stop letting your emotions rule you and engage your brain.
Re:Initial reactions (Score:2)
Not really. By including even an outdated JVM, they support at least Java 1.1 applets. Many people get nervous when their computer offers to "automatically" install functionality. So on WinXP, when the browser asks if they want to install a JVM, they may answer no. That means that web sites using Java will not work properly, so they will choose other web sites. In the end, this has the effect of convincing developers to use something else for their sites. But you also have to remember that the original reports of WinXP not including a JVM made no mention of an automatic installation on the first attempt to run an applet. In that scenario, many many users would have been turned away from sites with Java applets.
I'm sorry, but the original poster was correct. Your argument is horribly inconsistent and flawed. If it is evil for Microsoft to include Internet Explorer, it is equally as evil to include a JVM.
Actually, the original poster wasn't so much making a statement as asking a question. But it is your argument, my friend, that is most unbelievably flawed. You conveniently glance over the fact that Internet Explorer is a Microsoft Product, whereas the JVM is a Microsoft implementation of a competitor's product that would ultimately aid the competitor. Your own logic is flawed because you are making the assumption that the consequences of both of these situations is equal.
And I hereby declare that bundling lilo into RedHat is evil because it kills competition in the boot manager market. RedHat's purpose is obviously to damage the market that System Commander operates within, without providing them adequate compensation.
And this very statement here proves that you don't understand the situation at all. RedHat doesn't even have a monopoly on Linux distributions. You, like many others, forget that Microsoft has a monopoly in desktop operating systems. Period. This changes all of the rules. We absolutely do have a right to say what we think should and should not be included in the Microsoft Windows distribution because of that monopoly. (Actually, we have a right to SAY whatever we want, but you get my drift).
Re:Initial reactions (Score:2)
The W3C standards for HTML and such are formulated solely by Microsoft? W3C is owned by Microsoft? What?
The JVM is, an implementation of the Sun Java standards. It is just as much Microsoft's product as is the browser.
Before calling someone's logic flawed, maybe you ought to stop and think for a few seconds.
Re:Initial reactions (Score:2)
You seem to be a little confused about a few points sheldon.
Internet Explorer is a lot more than "HTML and such". It's Microsoft's own stated position that IE is a "platform", not a "product". It's the add-ons in IE that allow it to compete with the Java Virtual Machine
Note that I said Java Virtual Machine, rather than Microsoft Virtual Machine, which is what I believe you're talking about. In case you missed it, Microsoft is no longer allowed to call their VM "Java", because it's not an implementation of the Sun Java standards. The Microsoft Virtual Machine is in fact competing with Microsoft Internet Explorer, so it's a perfectly sensible decision to stop shipping it. However, that removes even the semblance of Java support from Windows, and further strengthens the IE platform and marginalises the Java Virtual Machine platform, something that Judge Jackson picked up on in his verdict that Microsoft are running an illegal monopoly.
Is that the point that you're missing? You're quite right that there's no reason why Microsoft should distribute a VM or JVM, but by not doing so, they put a strangehold on another competitor, and when you have a monopoly position you are (all together now) not allowed to do that.
Perhaps you could do some more research and then get back to us, and we can have a productive discussion.
Yeah sure... (Score:2)
Spare us the BS, will you?
To start with, Lilo isn't owned by RH, nor is it commingled into RH -- you don't want it? Removing it is trivial. Plus, if you're not happy with RH, you can go with Mandrake, which comes with GRUB, and which is still fully interoperable with RH.
MS may not be the Absolute Evil
Re:Initial reactions (Score:2)
For completeness, I'll just point out that I said that it "concerns" me, not that I'm judging it. I like Java, but my target audience is Joe Windoze running Internet Exploder, and anything that makes it even marginally harder for me to get my creations running on screen is a bind.
YES, I know it's an automatic one-step, and that it's only 10Mb, but that's one step and 10Mb more than I'd like. While I enjoy griping about the impatience or laziness of end users, I also have to cater for it. And I can't see it getting any easier in future, which is why I can see myself using J# and (ouch) contributing to the stifling of Java on Microsoft platforms.
Re:Initial reactions (Score:3, Informative)
* I have to make exactly zero changes to my Java to have it compile to both VM bytecodes and to a
That won't be possible. The
That's not to say that the
All Microsoft are facilitating with J# is allowing developers who know the Java language syntax to develop
Re:Initial reactions (Score:3, Informative)
- java.applet
- java.awt
- java.beans
- java.io
- java.lang
- java.math
- java.net
- java.security
- java.sql
- java.text
- java.util
along with a bunch of 'com.ms.*' packages.I just compiled a couple of small java applications one (TCPMapper) uses sockets and another was a multi-threaded AWT app. Both compiled without changes into small .EXEs (11K & 25K respectively) and ran fine.
Also, I downloaded PC Labs' JMark1.1 which comes only as .class files (no source) and used J#'s jbimp.exe which converts .class files to a .NET assembly (.EXE/.DLL) - very cool. It ran fine also, and gave reasonable results, although MS's JVM was quicker overall. Still some room for improvement on performance there, but given that the JVM's been around for a while, and both J# and the .NET system it uses are still in beta, it's pretty imprssive nonetheless.
Re:Initial reactions (Score:2)
Ouch. I was hoping that it would be like Visual J++ where a simple registry tweak lets you use whatever JDK API's you want. Are you sure I still can't do this with J#?
I know, I should really go and check this for myself. ;-)
Re:Initial reactions (Score:2)
Basically, I can live with loading J# and hitting compile once for each of my Java projects. If it's any more hassle than that, I agree, it's not worth my while.
If you're going to be doing this kind o stuff, whats the point in using Java / .Net AT ALL?? If you're going to have to re-compile for seperate platforms, Java has lost its prime benefit. Personally, if I'm going to be re-building anyway, I'm going to use a faster solution, like C or C++.
Re:Initial reactions (Score:2)
For me the prime benefit is write once, run anywhere. I really don't mind building twice; that's just computer time, and computer time is cheap.
Which is my point! If J# will compile my Java to a native executable which runs faster, and my extra cost is hitting one button (and making myself a cup of coffee while I wait) then it's a positive benefit, especially as my target market is mostly Joe Windoze anyway. Hurrah for Microsoft (sort of).
If I have to re-train, or it requires extra development time or managing multiple source then you're right, I might as well go back to conditional compilation hell. ;-)
increasing size of sun VM????? (Score:5, Insightful)
Go check out Opera or netscape, both have an optional download for the JRE 1.3.x. I think it was about 6MB. The JRE includes everything you need to run Java applications. It is hardly bigger than MS jvm and does a lot more.
Incidently, there is currently a beta of an enhanced 1.3.1 JDK that includes an activex component that fully replaces microsoft's JVM. Yes that's right, you can now run all your applets in IE using jre 1.3.1. Of course it doesn't support the MS specific extensions of the JVM.
so Java is ... (Score:3, Funny)
J# vs. C# (Score:3, Informative)
Re:J# vs. C# (Score:2)
All that does matter is where there is propper support to back you up, and by looking at Visual Studio
As long as the language allows me to implement my OO design elegantly, or at least easily, then I'm happy.
(thus VB will always suck be default)
I'm just happy I can use my Python, and ocationally meander into C++ and C#.
Re:J# vs. C# (Score:3, Informative)
Case in point: Java has checked exceptions, C# does not. The extensive use of exceptions in large projects is typically a significant source of program instability if you do not have the benefit of compile time checking. This is a very simple language feature, but it makes a major programming mechanism from one that requires caution to one that is ubiquitously useful.
Even carefuly selected syntactic sugar can make the code clearer and simple and cause some boost in productivity as a result (e.g. 'foreach' in C#). Of course, badly selected syntactic sugar can have just the opposite effect -- massive confusion. I find it astonishing that in C# you can never be sure what the expression 'a.b = c' does (assignment or function call). Are the several characters that are saved from 'a.setb(c)' worth the amount of programming time that would almost certainly be lost due to misunderstandings? I very much doubt it. (although anyone who has public members probably deserves that)
So languages do matter, and even the small differences can have a big impact on the stability and maintainability of a large program.
Re:J# vs. C# (Score:2)
All I'm saying is that it's more important to design, than what language you use. Mostly the client dictates the language, so that does not matter to me.
I agree that a.setb(c) is a good(tm) thing. Implicit operators can cause a lot of trouble only for the sake of a few less keystrokes and the illusion of a powerful language.
;)
But then there is also unneeded features. Yes, sure, so some features let you implement much closer to your design, but as long as you solve the problem in an easy maintainable way, with the least amount of conceptual bugs... that all dandy!
My private views differ from these, as these are my professional client-oriented views. Privately I still think next to smalltalk, Python is the best thing.
But I'm just stupid that way...
;)
PS: One can still do an OO designed and implemented program with:
~> cat
... but then one would need an infinite troop of monkeys.
Re:J# vs. C# (Score:3, Funny)
Re:J# vs. C# (Score:2)
<meeting
<emote>grin</emote>
But seriously...
XML may be heavy, but it has it's advantages. Wrapper tools can wrap it so that you don't even know you are using it, and you can compress it down to almost nothing anyway if it bothers you.
Re:J# vs. C# (Score:2)
One of the major advantages is that they're automatically integrated into the intelllisense argumnent completion stuff, so when you're writing a call to a method that is XML commented, a tooltip appears which show the type of the current argument and a free-text description of that parameter.
check this article [squiffler.com] for an excellent overview. if nothing else, check out the last screen-shot for an example of the power of XML/XSL.
Stupid Question from a Non-Programmer (Score:2)
Consider me clueless, and provide me with clue, please:)
It's about debugging. (Score:4, Informative)
The main advantage is here: development is faster in a team where every programmer can use the language he/she likes the most. Even if you're not familiar with C++ in the example above, you can pinpoint the developer who wrote the component that in line xyz his code bugs when you supply it the parameters your VB application passed to it. File the bug your bugtracker system et viola. The C++ developer can even use your VB application to debug his own code, without having to write a testapp in C++ that will supply EXACTLY the same inputparameters.
With COM and COM+ you don't have that.
Too many languages (Score:4, Insightful)
but
development is faster in a team where every programmer can use the language he/she likes the most.
Is it really? It hasn't been tested in the real world yet. IMHO, that's not a team, that's a collection of individuals going off in all directions. IMHO a project that's written in 5 different styles in 5 different languages would be a 'mare to maintain, extend or even to complete.
I'm all for picking the right tool for the job, and writing the project in the best language (or two) for the job, but in a medium-to-large project, it is important that code is collectively owned, well-integrated and understood by more than one person.
How will that work if everyone codes in thier pet language? Do you now expect Joe VB to learn not one but ten new lanuages? Or to not understand 4/5 of the project he is working on, even with the source? Language choice should not be made on personal whim, but as a group decision on language suitablity.
I see this as having the potential for of a whole new level of code impenetrability.
...when you take debuggingtimes :) (Score:2, Insightful)
Component based development is all about not caring which language the component is written in. Therefor in theory the language is not important. For debugging, it can be helpful. the CLR provides you that helpful tool.
Re:It's about debugging. (Score:5, Insightful)
.NET people love to say this and it makes me laugh. It's so naive. It's like saying that development is going to be faster once you let all the programmers use the bracing and indent styles that they personally prefer.
"Welcome to the team. I wrote the C# parts of the application. John writes in Eiffel, Paul here likes C++ and uses that, and George over there prefers to use VB because he really likes its type system. You'll be sitting at this desk here, and you'll be in charge of the code that Ringo was working on before he left. None of us really knows how it works because we don't know INTERCAL."
I submit that development is faster in a team where all the developers are using the same language and can at least read each other's code. I work with a bunch of guys on a successful Java-based scientific application. We have to go into each other's code and change things all the time. They're all smart guys- and I have real respect for them, because 1.they're very productive and 2.might be reading this. But they're physics PhDs with no formal CS training, and they write fiendishly clever code that is really hard to read. The best of them writes huge amounts of complex-flow infrastructure that is riddled with "historical" stuff that gets coded around everywhere. Another one writes impenetrable clockwork mechanisms. A third delights in purposeful obfuscation (so he handles the licensing validation code). If any of them were on a plane that got hijacked, the company would be in serious trouble! Their code is pretty hard to read, but I can usually figure it out because I'm used to deciphering uncommented Java. The mere idea of these guys running around writing different parts of the code in their favorite languages makes me shudder. (The clockwork mechanism guy likes OCaml, for example, and naturally the obfuscator would prefer C.)
The idea of everyone coding in their favorite language only works well if each developer is going to be entirely responsible for his/her own domains of the code, and nobody will need to cross boundaries too often into other domains. If there is more coupling than that, then soon everyone has to learn everyone else's favorite language. This sets up a language holy war. It also makes it difficult to reassign responsibility for parts of the code because now you have to worry about who knows what language.
This might be useful for more loosely coupled development teams. As in, your project in language X could really use this nice new library that someone wrote in language Y. But you can already use language bindings that are already available for that purpose. If you encounter a bug in a library do you normally debug it yourself? If you're like most people, you either send a nasty email to the guy who sold you a buggy library, or you dig through a mailing list archive to find out what the problem is. If you use a debugger at all, it's to get a general idea of what's going on so that you might get an idea for a workaround to put in your client X code. But you can usually just pull that off if you just have the source! It is kind of neat that you can step into a different language, but it's unlikely to be of much critical importance for reasons that have more to do with humans than computers.
It's about component based development... (Score:2)
Re:It's about debugging. (Score:2)
Why do you not see that perhaps part of the components your application might call could be reusable enterprise components developed and maintained by someone else... or third party components you have purchased?
You don't understand what
Also... (Score:3, Interesting)
Also, you don't have to register your components anymore. With COM/COM+ components, you have to register them in the registry. This is not a problem, but updating registered components is. In n-tier webapps, where the webserver has loaded the components in its core process (or separate process, if you've tuned it that way), you can't overwrite the dll and re-register the new components, because the dll is locked (which makes sense). Witb the CLR, just dump the dll in the dir and off you go. Updated the dll? overwrite it. The CLR will automatically see that the file is updated, and reload the components into memory.
Re:Stupid Question from a Non-Programmer (Score:2, Interesting)
CLR provides all that and much more.
Re:Stupid Question from a Non-Programmer (Score:2)
What does it DO? (Score:3, Insightful)
Later in the "article", it says that J# INCLUDES technology that enables customers to migrate Java stuff to
Having said all this, I don't see that there would be a big need for this.. Most Java developers and companies using Java are using Sun's VM's and technology and won't be migrating to
Can someone enlighten me?
Re:What does it DO? (Score:4, Insightful)
J# lets J++ and most Java developers get in on the .NET action. I say most because the version of Java supported by J# is 1.1. And yes, almost all of the hardcore Java developers are using Java 2 now (as they should be), but there's a large percentage of people still coding to the 1.1.x standard, either because they're still doing applets or because they haven't gotten all that serious about Java development.
The Java code doesn't compile to Java bytecode, but instead to CIL, the Common Intermediary Language (formerly MSIL), so that it can run under the Common Language Runtime, just like C#, VB.NET, JS.NET, Perl.NET, Python.NET, etc. It improves the interoperability because I can then take any Java class and use it like it was any other .NET class. Someone write a sweet applet or chat server or ssh client in Java? Cool, I'll take the .java files and compile them to CIL and now I can use the classes directly in my C# programs, extend them, whatever, just like they were C# files. And vice versa, and with any other .NET language.
Personally, I know it's not officially a migration tool, but I view this as more of a migration tool than anything else. Otherwise, you're going to be left using an older version of Java. It's important to note, though, that Microsoft isn't alone in this Java on .NET thing, so I think a lot of people need to calm down about it. What I mean is that other companies are going to be putting the Java language on .NET, just like other languages are being ported to .NET. And these companies will be using Java 2. So, I don't think that anybody should dismiss this concept just because Microsoft itself is only supporting Java 1.1 with it, because it's going to happen. For now, though, it is an important release so that Microsoft can support their Visual J++ users. As for a true migration tool, that's the JUMP tool (Java User Migration Path to .NET), which is coming out later, and from everything I've heard, will be for migrating Java 2 as well Java 1.1 code, probably to C#.
That said, I think there's a good benefit to it. A lot of Java programmers just flat out like the language, the whole WORA jive never mattered to them. It's really not a huge event, though, it's just one more language coming to .NET. One interesting thing, though, is that .NET programs run quite a bit faster under Windows than Java programs do. So, once a current Java is on .NET (and probably also a little bit with the older Java available via J#), Java on .NET is going to be pretty tempting to people wanting to squeeze better performance out of Java, especially if they really don't have much interest in non-Windows platforms. Interestingly enough, Microsoft could parlay this into its advantage in that .NET platform could ironically enough become the best platform on which to run Java programs. (Based on the few ports I've played around with in J# today, my really tiny code ( < ~30 LoC or so) runs faster in the 1.3.0-C JVM, while the larger stuff is running faster in the .NET CLR.)
Anyway, I really like the move, I'm glad somebody has finally put something out there which separates the Java language (which is pretty nice IMO) from the whole Sun vision of Java as a platform. Hope this helped...
Re:What does it DO? (Score:2)
Re:What does it DO? (Score:2)
Migration for Visual J++ developers (Score:3, Insightful)
It would not make sense to suck "Java" into the
Why? (Score:3, Insightful)
I cannot create standalone applications with J# so I had to learn C# to do them anyway.
J# is not compatible with Sun's Java so I can't use them together.
Sun's Java runtime is available for Windows(tm).
C++ is faster than C# so why would I use
Re:Why? (Score:2, Informative)
C++ is marginally faster than C#. However, C# is Hella easier to code in. No worries about pointer-math. No concerns about garbage collection. You don't have to write COM interfaces... I can write code that does the same job, in half the time that performs at 98% the speed it would if written in C++.
With the time saved, I can go home and download more pr0n.
Welp, the Register has a good article on J#, too (Score:3, Informative)
Apply here to screw Java: Microsoft recruits more J# developers [theregister.co.uk]
CLR - whats the advantage? (Score:2, Insightful)
People already have written cross compilers to compile C/C++ into java bytecode. BUT, AFAIK, not that many people actually use it. most people just go ahead and make the jump to using java as their programming language, instead of trying to remain on their old language.
by the same token, if you're going to use
Competition never hurts. I welcome J# completely. (Score:5, Interesting)
The issue here is that *many* Java developers have been trying to code quality front-end applications on Windows using Java -- and have failed (or fallen very short). *I* am one of those people who have done so. I know many other Java developers who have failed to meet their expectations reasonably when coding on Windows.
If I know that my target platform is only going to be Windows, but I can't use any of the Windows libraries... what good is Java? Its not. So I have to go back to C++. But C++ is a horror in its own ways.
Too many in the Java community are zealots about what Java should and shouldn't be used for. The idea that if it isn't WORA (Write Once Run Anywhere) then it shouldn't be written in Java is completely ludicrous, IMHO.
Some Java developers want the elegance of Java with an easy way to utlitize Windows native libraries without having to write convoluted JNI interfaces all over the place.
The answer is J#. However, I was perfectly happy with the idea of C#. C# has some compilation advantages and syntax advantages over Java that I really love.
I have extensive experience with Swing (Java GUI libraries), and they just simply don't cut it for serious front-end application development. The more complex controls such as JTable and JTree are full of bugs, they are difficult to use, and complicated. If you want less complicated controls, you have to buy a proprietary vendor's API and use those, instead. The Windows 'look and feel' does NOT look and feel like Windows. Because of the MVC design, you have to import practically every single class in Swing into your programs.
AWT was much more compact and easy to use. It also was pretty snappy; however, it suffered from lack of GUI controls.
I don't see anything wrong with J#. If it works for you and serves your purpose, use it. If it doesn't, then don't.
But a little competition in the Java marketplace (or any marketplace) never hurts. Maybe it will light a fire under Sun's ass and get them to contribute more to the front-end side of Java -- which has been ignored for far too long.
Better yet, maybe they will open-source Java, instead. Even better.
Open source non-Swing Java tree and table Java (Score:5, Informative)
Actually, if you are looking for less complicated tree and table components, check out the ones included with Ganymede [utexas.edu].
I wrote them because I needed them for Ganymede development, and Swing hadn't quite come along yet. I kept them because they are simple to use, they are pretty high performance, and you can do fancy tricks like node dragging ihttp://www.arlut.utexas.edu/gash2/doc/javadoc/arl ut/csd/JTable/baseTable.htmln the tree with little-to-no effort.
You can read the Javadocs on them here [utexas.edu] and here [utexas.edu].
They are licensed under GPL, along with the rest of Ganymede.
What we really need instead of J# (Score:2, Insightful)
"No one will use it" (Score:2)
Re:.NET (Score:3, Informative)
Check out http://www.microsoft.com/net/whatis.asp [microsoft.com] for an explanation on what .NET is. Take special note that .NET is not the Common Language Runtime, or the C# programming language, or Visual Studio.NET, or Visual Basic.NET, or the SOAP Toolkit, etc. Those are part of the .NET Framework, or the platform that enables you to build .NET services (since .NET is all about XML-based web services).
As far as what benefit you gain, that's twofold. With the .NET Framework, specifically the Common Language Runtime, you gain the ability to easily work with objects across many different languages, without any grunt work to get in the way (such as making sure you write everything as a COM object, and doing your own reference counting, and making sure you initialize and deinitialize COM). And since all the objects from code targetting the CLR are exposed as COM objects, you can even use them from languages that don't support the runtime, such as C, non-Managed C++ (aka, C++), VB6, Delphi, or any other language that supports COM objects.
.NET itself is more about server-server communication over the web. By passing around SOAP messages (via SSL, when security is an issue), you can implement anything from alerting users that they're being out-bid on something like eBay, to providing stock quotes more easily (without having to "scrape" html pages), to offering choice hotel information when you book a plane flight, and so on. Yes, all of that can be done now, but .NET aims to make it much easier. The potential for XML-based web services is pretty much bounded only by your (editorial your) imagination, and since it's all based on standard communication methods (HTTP(s), SOAP), you won't have to define new protocols for passing data around each time you want to do something new.
There are similar things out there, such as XML-RPC, but they don't focus as much on providing web services as .NET does.
Re:.NET (Score:2, Troll)
In short
This is Flame Bait and I am a Troll, Please moderate accordingly.
Re:.NET (Score:2, Insightful)
Differences are only that for the JavaVM there are much less languages available (besides Java itself Python and maybe some other language), where for the CLR you already have (besides C# and VB) Cobol and Haskell and even more languages.
Also, Microsoft seems to market
Re:.NET (Score:5, Informative)
These sorts of apps are not very sexy compared to writting an OS or a game or something, but they're what 90% of developers in the world work on.
A typical enterprise app will need to have a bunch of different front ends (e.g. web interface, a simple gui for data entry clerks, a bunch of reports) etc. Also, you'll have lots of people working on different bits and peices, and lots of changes going on all the time, e.g.say a sales manager comes up with a new promotional scheme that gives volume discounts you need to update your app to handle the calculations.
So with all these people working on apps that are evolving rapidly, you can end up with spaghettii code pretty quickly. If you want to have something that's maintainable, you really need to use OO and come up with an object model that seperates the user interface, the business rules, and the data layer.
The problem with this is that it is hard to have an object model that works well over distributed systems, and hard to have an object model that can be used by developers using multiple languages.
COM is a start to allowing objects to be used from multiple objects, and over distributed systems, but it has limitations, largely related to the fact that different languages don't have the same idea of basic data types.
.NET solves this by making all languages share a virtual machine that defines a bunch of basic data types, and a base 'object'. This means that any object created in one
So you can have a your web front end people write ASP (VB) pages that interact with business logic written in c# without having to compromise your object model.
Re:.NET (Score:2)
Funny, I though I had ASP(VB) talking to C++ years ago with COM and MTS (althought I hated working with ASP).
I admit that the common language runtime is a good idea, but more evolutionary rather than revolutionary (virtual machines have been around for a while).
After that there is not that much to .NET other than marketing. XML-RPC is a good idea in a lot of cases, but it is not like Mirosoft invented it, or is the only one doing it. Passport and Hailstorm ore likely never going to fly in the marketplace - how many people, even PHB types, who would really trust Microsoft that much?
So .NET = selling CORBA to suits? (Score:3, Insightful)
Okay, so, in terms of functionality, how does that differ from CORBA, where you can very easily call a complex method written in Java on an Alpha box running OSF/1 from an object written in Python on an x86 box running Linux?
Outside, of course, the fact that CORBA is a fully documented specification [omg.org], meant to be completely open and interoperable, complete with mappings for data types and everything, and that you don't need a virtual machine to make it run where you want, the way you want?
Please note -- it's not a troll. I'd just really want to know.
Re:.NET (Score:3, Insightful)
There's a simple answer to that - because you then give the company the power to screw you. The question is not sticking to one company, but choosing a partner that uses open standards which do not lock you in.
Microsoft is beinging to turn the screws by increasing their licencing fees, which at least in the UK is upsetting an awful lot of big organisations. They are only able to do this because of their 'vendor lock-in'.
Re:.NET (Score:2, Informative)
Let me give some input from the perspective of a systems engineer rather than a software developer. Someone who has to run the crap you programmers put out.
That sounds like a marvelous idea. And the next time a nasty virus/worm creeps in that exploits some flaw in Outlook, you've just lost all your corporate data because that worm will crawl from component to component thrashing everything in its path, completely oblivious to Microsoft's so called security. All in the name of integration. Does it still sound like such a great idea? There's nothing you as a developer can do to stop it, because all you're doing is writing tools for a fundamentally flawed platform. You can't fix the platform, and you can't choose a better one. You're locked in to Microsoft.
There's nothing wrong with using a single vendor as long as you're not locked into that vendor. Any production systems engineer will tell you there has to be a back-out plan before you make any change. Where was the back-out plan when people started choosing Microsoft? With Unix, if you don't like one vendor, choose another. If your code is well written it takes little to no effort to port it and recompile (if any porting is even necessary). Switching from MySQL to Oracle? I don't know about C, but in Perl, it's as easy as changing one line of code (if you were foolish enough to hard-code your DSN string). Want to port your business logic server but not your clients? If you want to switch from Microsoft to some other vendor, well.. Good luck, and have fun re-writing your application from scratch. I said I'm not a developer, but I'm a systems engineer who occassionally writes useful tools to make my job as a systems engineer easier. I write AND TEST those tools on my desktop Linux box. I run them on $500,000 Sun Solaris servers. I generally don't even have to change one line of code. I can do that in C/C++, Perl, PHP, Java, Python, and any number of other languages. I can even write a program in C that interacts with another program written in Perl. Try writing a tool in C# or VB or some other new proprietary Microsoft language or even one of the standard languages like C. Now try compiling that code and running it on a Sun server. Won't work.
The people who think Microsoft is the best solution, generally have lived their entire lives locked into Microsoft and don't know of a way out. This is how Microsoft has made its billions, and how despite all its devistating flaws, remains a top competitor.
Re:.NET (Score:2, Interesting)
whereas the people that point out that he is *wrong* get modded to zero.
fucking idiots.
anyway, the parent to this dudes post raises some good points - but I'm curious if
all I know is that I spend all day programming business apps as that guy said, and java sucks balls, but I'm not certain that
oh and, linux linux linux - I run it, I also run all the MS OS's - so let's see how I get modded.
fuckers.
Re:.NET (Score:2, Interesting)
I'm writing an application that will bring our e-commerce site for my company into
We, then took that code and re-wrote it in
Just to see if it was the JIT compilation that gave us our performance jump, we compiled the same logic into a COM object, and ran it through ASP and
The advantage here is clear - You get the same level of maintainability with
Re:No you can't (Score:2, Informative)
Its not that
Currently with COM, cross language inter program communication (or cross machine program communication even in the same language) a lot of time has to be spent reading, interpreting, and converting data types (especially object types) into the native language of the program. So if you had a payroll tax program on another machine and you wanted it to update your employee record (object), you might have code that reads something like:
UpdateTaxes(MyEmployeeObj)
Under
Under traditional systems, the object your passing has to go through packing and unpacking of each field, in both directions
Re:Control (Score:2, Funny)
This is actually an interesting idea. Maybe you could use Java to write an interpreter for your own custom bytecode. Then you would run it using the Sun JVM running on top of the CLR VM and get THREE levels away from the native code. The ultimate would be a VM written in the same bytecode that it interprets. Then you could just stack those VM layers up like Legos to the sky! There are probably some good IOCCC entries in here somewhere.
The real question is: if
Re:Control (Score:2)
Squeak [squeak.org] actually has this. It's pretty nifty: a VM for Smalltalk written in Smalltalk, so that it can self-host. It's slow, but it works. The Smalltalk is translated into C and then compiled natively, of course, to build a runtime, but the reason why this was done was to aid the developers of the system in debugging. (They are Smalltalk zealots and do not like messing with icky C.)
Re:Microsoft turned their backs on... (Score:2, Insightful)
Re:More importantly :how to pronounce J# ? (Score:3, Funny)
So: Jis
which I will comment no further.
Re:More importantly :how to pronounce J# ? (Score:2, Interesting)
According to The Elements of Typographic Style by Robert Bringhurst (a standard and
highly-respected reference in the field), the
character "#" is named "octothorp". The origin
of this name? "In cartography, it is also a
symbolfor a village: eight fields around a
central square... Octothorp means eight fields."
(Insert appropriate wisecrack here...)