Slashdot Mirror
J#
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".
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).
J# seems to me just a cross between c# and java.
I dont really see of yet another langauge designed for web depolyment.
what would you do?
:- if you were a director/shareholder of a company like Microsoft would you
.NET that ultimately play back into your desktop Windows (XP) market, or
- 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)
consider coffee a lubricant that helps one penetrate the coding zone
Very funny. If you knew anything about music, you'd know that C# and D flat (curse this character set) are not quite the same note. They are on the piano, but not on stringed instruments.
There is always the fact that Java is being natively excluded from Win XP.
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.
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?
Reality or nothing.
Is it a good idea? I can see that it would be - if it weren't for the small point that it only runs on Windows. If you're only going single platform then surely you'd be better off going native code and just using the same compiler back-end for all languages (as Borland do for Delphi and C++ Builder - which both run like sh*t off a shiny shovel).
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.
This sig made only from recycled ASCII
the Java COM developers. So we picked up and said well hey maybe this isn't such a bad thing, let's go find our roots and discover what this J2EE platform is all about. Besides M$ has given us a boloated crappy VM anyway. Hey who needs this XP thing anyway?
Now that they see most of us, developers have picked up and left this is M$ brainchild to suck us back.
Tsk, Tsk Bill, You've got spunk... Sadly though, unlike other companies Microsoft can easily pay for the mistaken direction that they've taken.
"It takes many nails to build a crib, but one screw to fill it."
So, Java isn't a part of XP. So what, it isn't a standard part of Linux either, and nobody's complaining about that. Of course, I don't personally know of anybody that does run Java apps on the desktop...
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
Trust the Computer. The Computer is your friend.
Yeah yeah, J#, GNU# ha-ha. We've heard all the jokes and M$ spelling already. Now can someone please explain what J# actually DOES cause the Microsoft site doesn't seem to explain this. Does it operate on compiled bytecode? Does it translate the source code? To what language? C#? The site says that J# "improves the interoperability of Java-language programs with existing software written in a variety of other programming languages". That doesn't sound like just a migration tool to me. Also if it's just a migration tool, the name is pretty misleading since most people assume it's a language (C#, J#, ...)
.NET. But I still get the impression that J# is more than just a migration tool.
.NET. Most Visual J++ developers were writing Windows-only, client apps - not server side stuff, so I don't see that they would benefit from this either.
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?
On the whole, the not-bundling-java thing is actually making Java developers' lives easier. Why? Microsoft's Java hasn't been updated since 1.1.
Java has moved on from there a hell of a lot - 1.3.1 is the standard, 1.4 is in beta - with (a) a completely different GUI system (swing), (b) completely different I/O system (nio), (c) built in XML parsing support (jaxp), etc, etc.
Now, if you're an online-stock-trading shop that depends on Java for your complex UI on the client side, you can be more confident that the client is using an up-to-date JVM, since they've had to install the latest version, like realplayer, etc.
I believe this is merely Microsoft's solution to provide a migration path for the Visual J++ developers who have been left high-and-dry since the discontinuation of that product. The references to "other Java language" is just a red herring.
.NET platform, when a language so close to Java (C#) has been expressly created for that purpose.
It would not make sense to suck "Java" into the
Not saying this isn't true, but this is all already possible with Java.
.NET better, of course five years ago Sun was slightly to early with their Java platform (but they needed that time anyway to manture Java).
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
(-% TwistedMind %-)
You are right in that the advantage of CLR is that it is a level of integration better than COM, which is itself a level of integration better than the flat-DLL/library API function call interfaces that the original poster was happy with.
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.
My Karma: ran over your Dogma
StrawberryFrog
The main advantage is here: development is faster in a team where every programmer can use the language he/she likes the most.
.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.
when a team develops a product, you'll have different aspects of functionality implemented, by different kinds of people (both on skillset and on interest). When these people are offered to make it possible to develop in the language they like, it's an advantage, and because component based development is a way to speed up devtimes, it's a plus that people can choose the language they like. However, in the COM/COM+ world, others can't debug your code. (VB-VBCom components, ok, but with different languages, that's a problem). When they CAN step into your code, they can pinpoint to the errorous lines or blocks of code that could be wrong, directly. This adds another speed gain over COM/COM+ development.
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.
Never underestimate the relief of true separation of Religion and State.
At the end of the day, if can happily do everything I need to do with one company, why not stick with them?
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'.
Could someone explain to me why would I start to code J#?
.NET?
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
I keep reading about this on sites like this. It should be pointed out that even the JRE (java run-time environment) for jdk 1.4 is well below 10 megabytes (mainly depending on the platform). Of course if you download the full jdk you have a bigger download, mainly because that includes, among others, various tools and the source code for most of the API. But even then we are talking about 30 or 40 MB.
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.
Jilles
If Microsoft includes a Java Virtual Machine within Windows, it kills the potential competition in the market there for JVMs.
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.
i find it strange that microsoft would choose to try and 'leverage' the bytecode concept that java has. i keep hearing from developers that CLR is cool, etc where i just keep thinking its the same concept as the java bytecode. .NET, then i would think you would want to learn C#. but if you are going to do that, why not learn java and then be platform independant? its not like learning java is that difficult for a proficient vb/c/c++ developer. C# keeps more of the c++ eccentricities. or as its been said "C# - it keeps all the worst bits of java AND c++"
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
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, 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.
-- B.
This sig does in fact not have the property it claims not to have.
Is a compiler that turns C# code into JVM bytecodes, so we can use the kind-of-neat C# language syntax with the mature Java tools. This shouldn't even be that hard to do (well, a little harder than a Java compiler). By the way, the CLR runtime supporting multiple languages is kind of a myth. Each language that the CLR supports has been rewritten (with new syntax, etc.) so it can be used with CLR. No code in an existing language will work with CLR without going through a migration. If you are going to work with CLR, you might as well use it's native language (C#) directly.
You're misunderstanding something, or you're a microsoft advocate. Java is not a goal, it's a tool.
/dev/nullsig
Sun is a commercial company, just like MS. They care a lot about targets, shareholdervalue, etc. Why do they develop and give a away something like Java?
The wintel platform is growing into the server market. Actually or potentially eating away SUN's marketshare. MS profits a lot from it's available software base: Why do people buy and install MS? Because there's loads of software for MS. Why do developers create software for MS? Because there's loads of people buying and installing MS.
If people develop or use a lot of Java software, they don't need to run a certain OS. Making them potential SUN customers. And if SUN operates from the (likely) point of view that their hardware/OS combination superior to the wintel combo, they would consider them likely customers.
If MS includes a fully comliant java implementation with their OS, they increase the likelyhood of a 'write once run anywhere' idea appealing to people, making them less dependant on MS. If, however, they include incompatible java-like implementations with their OS, they probably won't attract the Java-loving-crowd, but they still attract a lot of MS-loving-crowd trough the channels they already have. They are not going to explain to them that their product is not Java; even though their product is not Java they create diversion and inoperability in the Java-field. And if they play it smart enough they might even make people prefer te MS-Java-lookalike, because it's the only one compattible with with the MS-Java-lookalike software. This is why SUN is eager to fight lawsuits against MS.
Both introducing/supporting Java and introducing/supporting the non-Java could be valid business tactics. However, the MS-monopoly gives them the chance to pull their trick of; I don't know if using a monopoly to keep and increase a monopoly is evil, but it doesn't sound likely to be benefitting consumers.
---
Ewout
cat