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).
And in other news Microsoft has publicly announced plans for the following projects:
.org (DON'T even ask what it is)
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.
There is always the fact that Java is being natively excluded from Win XP. The conspiracy theorists among us would probably argue that this move is to have the J# initiative and thus the .NET initiative to be more successful and quash everyone else.
VBS# - killing two birds with one terribly ugly stone.
-- I'll cut you up so bad, you'll wish I'd never cut you up so bad!
I will never use D flat.
According to CNN, Microsoft's B flat is the programming language of choice of Osama bin Laden.
Spotted this on the GNOME Weekly Summary:
:)
Hello World in C# using the GTK toolkit
The syntax does look pretty clean.
It's not quite up to Java GNOME 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.
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
Check out http://www.microsoft.com/net/whatis.asp 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.
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.
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.
If you were blocking sigs, you wouldn't have to read this.
even more portable than before?!
Java and C# are already pretty similar...how am I going to know at a glance which one I'm looking at. Surely the differences between the two (which are subtle, but certainly there) will catch people up all the time.
This is the perspective of someone with a couple of years experience in "enterprise" development, i.e. apps that have a UI that is probably a bunch of data entry forms, a database at the back, and a "business logic" layer that looks at the input, massages it, acts on it, sends it to the db, etc.
.NET language can be accessed by another .NET language.
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.
In short
This is Flame Bait and I am a Troll, Please moderate accordingly.
Fascism should more properly be called corporatism, since it is the merger of state and corporate power - Benito Mussoli
Is it possible for someone, who knows what they're talking about, to tell me what the big difference is between COM, COM+, and CLR that makes the latter so "revolutionary"? As far as I can tell, they all allow programs written in different languages to interact with one another.
Consider me clueless, and provide me with clue, please:)
Someday, you're going to die. Get over it.
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?
So the Sun JVM would run on top of .NET? The JVM itself would be running under a CLR VM. Native code is now TWO levels below you.
.NET is only going to run on Windows then why does Microsoft need to set up a VM for it at all?
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
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
Ok, with COM and COM+, you could f.e. use a component written in C++ in VB or vice versa. However, when you're debugging your VB application and the error you receive is inside that C++ component, you're out of luck. (You can, in a way, compiled VB stuff in VC++, but it's a nightmare). With the CLR, you're not. You can step into that C++ component directly from your VB code. And if that C++ component uses a serie of C# components, no problem there.
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.
Never underestimate the relief of true separation of Religion and State.
(sorry for the separate message, but if I put this text in the other message I replied, Slash will time out. Please fix this)
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.
Never underestimate the relief of true separation of Religion and State.
Squeak 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.)
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
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
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'.
that's the bottom line. get a component's instance, set some properties, call its methods, get results, destroy/release the component's instance. From a developer's point of view, you don't care HOW that component is developed, with which language etc, just that it should do what it supposed to do when you call a method. The OP wonders what's the big difference between COM/COM+ and the CLR's model of component based development. YOU are wondering if component based development is better or not. That's not at stake here. Some say it is, some say it isn't (f.e. the extreme programming people). When you go for component based development, the CLR has the advantage over COM/COM+ that you can step right into the code WHEN IT FAILS. this is an advantage and CAN gain you time. If you don't see the advantages of component based development, you will never see the advantages of COM/COM+ and the CLR.
Never underestimate the relief of true separation of Religion and State.
Someone's going to attack you on the basis that Microsoft added extensions to Java...when they do, they're an idiot. Microsoft HAD to add stuff to Java to let it call COM, as Microsoft always supports its legacy code (as this J# release shows), so they needed Java to interoperate with COM. Sun weren't about to do that in a hurry (can we say "because they had a monopoly over Java which they attempted to leverage to force other companies out of business"? No? Do Slashbot weenies only accept that criticism when applied to The Great Bill? That's 'cos they're thick little lUn1X weenies.)
So: Jis
which I will comment no further.
bla
there's nothing in the CLR that is windows-specific. sure, right now the only fully-functional version publicly available is Microsoft's which runs on Windows, but there's nothing in the spec that requires windows featurs. In fact, there's nothing in the Win32 API that requires windows, either (see Wine).
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
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.
"We can make this work, but you're going to need a screwdriver, pocketknife and some duck tape."
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...)
Ahem. Only about 40% of the .NET framework APIs have been submitted to the ECMA. We'll see if the other %60 make it and in what form. :)
KangarooBox - We make IT simple!
Gotta love the title:
Apply here to screw Java: Microsoft recruits more J# developers
Sigged!
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
this is fucking ridiculous - this guy gets a mod score of 2 b/c he says "linux good, grrr, ms bad, grr".
.NET, since it is a VM on top of the OS, which is what Java is as well - does it run as slowly? or slower b/c it has more languages to work with?
.NET is the answer to it.
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.
There are some odd things afoot now, in the Villa Straylight.
This is not the same as perl.
.Net creates the possibility of writting code/systems that could not execute before, just that now, this code can run efficiently.
.net you'd be copying a chunk of memory, having the process update fields directly, and then copying it back.
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
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?
Do you even know anything about perl? -- AC Replying to Tom Christiansen post.
I'll give you some figures I compiled yesterday.
.NET-land. One of our concerns was bringing COM objects through .NET's interop layer (a translation layer between .NET and COM). We ran some code in ASP that manipulated a large XML dom 1000 times, and execution time took a pathetic 21 seconds (21348 ms).
.NET. The exact same operation took 1.5 seconds (1511 ms).
.NET. The same operation took just under 1.5 seconds (1487 ms).
.NET ASPX files as you do with ASP files, but you get the performance equivelant to compiled binaries.
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
--Quidquid latine dictum sit, altum sonatur.
First, a disclaimer, I am not a Microsoft advocate. Those guys can stick it up their ass. That being said, I will do what it takes to do my job and get paid.
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.
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.
And I hereby declare that bundling lilo into RedHat is evil because it kills competition in the boot manager market.
/. tends to make them, but trying to compare their practices with the way Linux works is not -quite- a smart move. :)
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
-- B.
This sig does in fact not have the property it claims not to have.
Like no-one used Divx, AVI, SMB, DHCP, active server pages, common object model, or the X box. They don't even have to ship stuff to sell people on it anymore. It's wonderful.
Decompilers are close to useless for maintenance activities unless you don't have the sourcecode (so either you threw it away, duh, or you're not supposed to have access to it). You do maintenance on sourcecode, preferably properly commented source code, preferably source code you are familiar with.
.Net or to bytecode is irrelevant. There's really only one certainty: migrating to .Net will generate additional maintenance activities since you will have to test whether it works and almost certainly you will encounter small problems. Once you have migrated and supposedly actually use the binaries you will find that you need to fix little things and even add new features from time to time. So you will keep tinkering with your old J++ code.
.Net languages. Also J# apps still use the rather limited 1.1.4 API and not the .Net API so it is really a tool to communicate with legacy J++ applications rather than to migrate those legacy applications (which eventually you may need to do after all). And once more: the whole problem of J++ applications being legacy software is because MS decided to abandon J++. First they charge you for a J++ development environment and now they charge you again for some crappy solution to let you keep using your J++ stuff. Probably the reason you decided to use J++ in the first place was to be compatible with the other wonderful windows stuff you paid for. You were screwed three times! If I had used J++ in the past, I'd be very pissed off. This also shows that you have to be careful to invest too much into C# or Visual Basic or .Net because MS may suddenly decide that they need some extra revenue and change things so much that what you invested in heavily suddenly becomes legacy software. Visual Basic changed substantially during its existence and generally 'migrating' apps between different versions cannot be done fully automatically (i.e. it will cost you). Just like with office it is highly debatable if the changes are worthwhile and that breaking compatibility is really necessary but you have no alternative so you upgrade and revise your old stuff.
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.
Jilles
Actually profits does NOT come before everything else - market valuation comes first ...
>Yes, I still don't know how to pronounce those C# and now J#.
In English (i.e. British english) # is called a 'hash' so that gives C(hash). Also to hash something is to bodge it or make a mess of it . All in all a rather appropriate description.
No matter what tools come on the scene, C/C++ will be my mainstay for performance-intensive code. Perl will be my tool of choice for glue and scripts. A SQL database or DB files solve my data storage problems. XML, HTTP, and HTML solve my interchange problems. I am not interested in giving up any of these as they have all proven to work.
So I ask Microsoft - where do I need .Net tools??
Joe VB: I was debugging an problem in the system, and i ended up stepping into your C++ code, where i found the bug. Apparently you derived your class from two different classes, both of which implemented the same function - void doStupidThing( void ) - and the wrong one was being called during runtime. You have to be carefull when using multiple inheritance. I've just patched it and it's working ok now.
Me: *amazed silence*
Your eventual price will be "cost to migrate everything minus $1 per period", where period is the time over which you have to justify the cost. Calculate what it would cost you to migrate everything out of your lock-in and then figure on paying that every one to three years.
You should also realize that you no longer have any control whatsoever about when you get to recode it all. That is entirely up to when the vendor (MS in this case) wants to ramp up revenue through releasing an upgrade that will break your code.
Wanting quicker/easier/less painful development is exactly why computers today are expensive, slow and unreliable.
I think no one can use www.J#.NET , simply because DNS can't handle those darned octothropes. And how is MS going to steal the whole .NET TLD anyway? Those wily Redmond punks fooling with the Domain Name System.... :)
--hongpong.com
I can already see the Sun ad campaign to follow the .NET initiative.
.NET too. ;-)
Sun: We put the "." in
This space intentionally left blank.
You'd still be using the Java API that way so it wouldn't help you much. The whole point of migrating to .Net is that you end up using .Net. Transforming the syntax doesn't really help since both languages are more or less equal in capabilities.
MS knew exactly what they were doing when they broke compatibility (presumably they can afford the legal staff to read a license) and it had nothing to do with improving the product. They expected that they could get away with it but were proven wrong.
They did implement AWT BTW. The problem was the way they called native code (i.e. they didn't use JNI). The only reason they did not support JNI was because that would allow them to create platform specific APIs in addition to platform specific implementation. MS always had the option to implement the necessary APIs but they refused to do so. Consequently, MS is entrirely to blame for the death of J++.
J# is Java without the Java platform (vm + API), except for the obsolete, partial jdk1.1.4 API. It is generally agreed that what makes Java so powerfull is the vm + API. The language itself is not very exciting really (your average OO language).
Jilles
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
Actually, if you are looking for less complicated tree and table components, check out the ones included with Ganymede.
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 and here.
They are licensed under GPL, along with the rest of Ganymede.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
This is irrelevant in Redmond. Because a key feature of
Perl, and what else have you notwithstanding. Somebody didn't take their soma today.
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
Almost all of the introductory CS text books use the Java language, and therefore, most intro CS courses teach Java.
This means that thousands of individual students, computer labs, departements, need to use Java compilers or IDEs. With MS no longer able to provide a Java implementation (more or less, I don't know the exact details), they faced the prospect that new programmers (at least untill the curriculum was switched to C#) would learn to program using non MS tools - MS looses the income from selling these tools, and faces the prospect that students 'comfortable' with products from another company might be harder to 'capture' as MS devotees.
By providing a J# compiler, those students can use (read, buy) a MS tool to do their assignments (especially considering that the intro assignments don't use the advanced features of the Java API, which are un-supported on J#) and start along the path of becomming happy MS developers.
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.
It sounds to me that python might be easy to fit into this situation. The syntax is familiar and relatively easy and it can import c/c++ libraries if you need to. And the documentation, fraught with Monty Python witticism, is hysterical. Python bytecode can be run on a jvm and I've heard rumors there is ongoing work to make it useable via .net, but perhaps someone else with have more info about this aspect.
Although I am looking forward to Perl 6 (which also is rumored to eventually contain .net compatibility), python is filling my needs where perl5 and java are too cumbersome.
It's the old blocking versus non blocking socket argument in disguise...
Blocking socket processing is often maligned , but this really is a legacy of Winsock and the fact they had to figure out how to get single threaded co-op multitasking for old 3.1 windows to serve sockets.
The reality is, at core Unix sockets have traditionally been blocking, because it's just to easy to fork() and catch them requests in multiple threads. It's better server programming, because a clogged or busy thread doesn't jammy up other threads, and
I had an article from the old winshoes delphi components (clasic example of how rad programmers should enter the open source community. good stuff) on why multi threaded blocking sockets are the way to go.
Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
Probably they will "Make Windows the best operating system to run .NET on" in similiar ways that 10 years ago they made "Windows the best operating system to run Microsoft Word on" by adding busy loops in their programs to slow them down if they detected that they were running in OS/2's Windows compatibility mode.
I'm not convinced (yet)
--jeff
ipv6 is my vpn
I've heard the expression cross-hatch used from time to time. I've not heard cardinal used but I've seen it used to mean [interger] number on forms i.e. Ref#