Slashdot Mirror
Visual J# .NET Released
Goalie_Ca writes: "Visual J# .NET was released at the Tech Ed 2002 Europe Developper conference today.
Visual J# .NET is not a tool for developing applications intended to run on a Java virtual machine. Applications and services built with Visual J# .NET will run only in the .NET Framework; they will not run on any Java virtual machine. Download it here; Microsoft J# .Net site."
Why would anyone really wanna use J# as compared to c#? It seems that C# was mostly a rip off of Java anyway... is J# just more Java like? I'd still rather use c or c++ anyway.
Visual J# .NET
Wow, what are the marketing people at MS smoking these days? They've obviously moved onto hard stuff. Rember the says of MS Bob? Marketing is a gateway drug.
Friends don't let friends join Marketing!
Using your sig line to advertise for friends is lame.
As a high-demand developer in the enterprise, with experience in C/C++, J2EE, and now C# on the .NET platform, I have to say it is about time.
.NET is the cost of porting all of the legacy Java code to the new application framework. J# gives real customers a low-cost upgrade path that won't break the bank or the developers' backs.
From what I have seen in the business world, the big hurdle holding many companies back from upgrading to
Now that Sun is being given some real competition in the virtual machine market, maybe we'll see some genuine innovation.
Karma: Good (despite my invention of the Karma: sig)
It's designed to run on a Java Virtual Machine but will only work on the .Net Framework.... This sounds absurd, why not just use Java? I'll admit I'm not to informed on the whole '.NET' strategy (frankly, don't care), but can someone educate me on the possible use of J#?
Rick
Making something out of nothing : MD5 ("") = d41d8cd98f00b204e9800998ecf8427e
With Java, one language can create a program that runs on many platforms.
With dotNet, many languages can create a program that runs on one platform.
So what happens if MS decides to create a CLR for other platforms. Than you have many languages that can run on many platforms.
WTF is the deal with this post!? Is it supposed to bomb some broswers, or it just annoying in general?
Microsoft released a new product today named BuggyWhip.NET, which they say will become the industry standard in "Horse Motivation Technology". A Microsoft spokesman was quoted as saying that the motivation behind this release was to prevent Visual J#.NET from becoming the most useless thing on the face of the earth.
I must be missing something important, because I don't see what all the fuss is about .NET. Sounds to me like the developer's analog to the 'XP' suffix, and little more. "Look, .NET is different. .NET is the greatest thing since sliced bread." .NET is just a name tacked onto every piece of software these days. Screw this J# crap, wherever Java is needed, Microsoft isn't, else we'd be using Visual Basic for that same crap.
-Billco, Fnarg.com
Think about the three components in this article's title. The prevailing wisdom is that their intersection is the null set, right? In fact, there are those who would say that about any two of the three. I can be as cynical as anyone else -- folks say cynicism is my Olympic-level sport; nonetheless, I think .NET and IT can work a great partnership with the real world. I want to offer some suggestions and examples below.
.NET to help your company.
.NET world with COM+ services and with Application Center, BizTalk, Host Integration, and SQL Servers.e nce.NET
.NET is not just the .NET version of our programming environment; it contains some truly neat tools for creating web services. It also contains the .NET framework as a unifying platform for any of the .NET languages, from VB to C# to Java to COBOL. (Click here for some thoughts about VB.NET and C#.) It's the way to write any custom code needed for .NET -- or pretty much anything else. VS also supports BizTalk with some specialized tools, particularly around business processes.
.NET. In just a few hours, they built a web service called Snax that tracks all leftovers. You can register food sightings, get e-mail alerts when there's food available in your building, or check the site at any time to see what's available. (As I write this, the site shows donuts and three different collections of Chinese food. This probably confirms whatever prejudices you already have about the tastes of Microsoft folks, although I'd argue that this is programmer-food anywhere.)
.NET?
.NET; I hope this series has been helpful to you.
.NET is important, and I've tried to share my reasoning with you. I don't mean it's important for Microsoft, though it is that; rather, it's important for IT departments that want to become more agile, more productive, more of a value-add for their business rather than just a cost center. I've gone into such detail because I want IT to matter.
.NET can make a real difference on that path to business profitability.
I'm not suggesting this is an easy partnership; the real world has all sorts of sharp edges and nasty corners. I think it can be a cost-effective partnership, however.
The following suggestions and examples are based on real-word scenarios I've encountered in my years of consulting; in a few cases, I've disguised actual companies. Some of these are enterprise systems, with others looking at smaller companies or departmental solutions. Some are Internet based, but many use only an intranet. There is no code here, nor instant solutions; my goal is to stimulate thinking around how you might use
Inventory and Supply Chain
Here's an example involving parts lists and distribution/sales. This example would work just as well with auto parts, or kid's clothes, or most other "goods" industries, but let's say I manufacture heavy trucks at Steve's Truck Yard (STY -- I was looking at my desk when I came up with this acronym). Dealers have franchises to sell my trucks, and I get parts from about 100 suppliers. I have a good inventory system, but getting supplies just-in-time from my suppliers is painful. It's a manual process to "exchange data" with the suppliers. If you've been here -- I think we've all been here -- you know that "exchange" is a nice way to say "reenter."
I can increase profits if I cut both inventory costs and stock-out situations; any time lag -- i.e., doing everything by hand, or by formula -- will cost us money and/or sales.
Likely approaches? I could do nothing; no cost, but no benefit either, and I'm in trouble if I lose the one employee who understands how it all works. I could build a connector to my suppliers using EDI and/or a lot of custom and one-off code. Or I could build that same connector quickly using BizTalk 2002 Server (which can also work with existing EDI solutions).
As noted in Part 2, BizTalk is terrific at helping disparate systems talk to each other. The harder part may involve people and not technology, but I have some ideas here too that I'll detail in the next column. (Does that make it Part 4 of this three-part series?)
First, much of the work may already be done. There are some 300 adapters/connectors linking BizTalk to other systems and software: Arriba and Commerce One, Oracle and SAP, Excel and Word, Java and EDI, CORBA and CICS and COM, oh, my, and hundreds of others. Why reinvent the wheel? The variety of third-party stuff out there is amazing. Second, some of my suppliers may already be looking at or even using BizTalk Accelerator for Suppliers; if so, my work, while not done, is lessened even further. Third, I could write an application adapter using one of BizTalk's component interfaces to feed data directly to and from my current applications.
It happens that STY is running a well-known inventory management system at the warehouse, so I can license BizTalk plus a third-party adapter for my end. This works even though that system uses not SQL Server but some database from a company down in California. And if some suppliers are running EDI or have an XML-compliant interface (I can dream, can't I?), connecting to them will be pretty easy.
There are three hard parts in this scenario: finding suppliers capable of and willing to exchange data and requests via the 'Net, connecting the various data sources, and writing the logic that actually does something with the data, such as triggering a reorder request when inventory reaches a certain level. The first (data sharing) is becoming easier and is even commonplace in some industries. BizTalk and its adapters take the hassle out of the second (communication). The third part (business logic), of course, is still hard.
But corporate IT should be pretty familiar with the needed business logic; it's the bread-and-butter of our systems. I do not mean to suggest that this problem is trivial, but I do believe it's manageable and has a relatively short payback time.
This isn't just about manufacturing. Think about seasonal goods, such as snow tires, or air conditioners, or lawn tractors. Whether you sell them or manufacture them, you must be acutely attuned to seasonal and market variations; the company that gets it right each year will be ahead of those companies that go with the average flow. And you've got to ship those goods; how many container-loads of your product will you ship Thursday? That's even more critical when you product is food; what's the value of having your systems talking to those of your long-haul truck dispatchers?
How often has business gotten it wrong?
We don't get many chances to be business heroes; jump on chances when they arise.
Intranet.NET
Desperately Seeking Services
It's easy to think of Commerce Server simply as an Internet commerce (i.e., money-changes-hands-in-a-transaction) tool. In fact, we make it easy to see it this way -- I presume because that's the reason most people license it. However, I think there are a few other ways it can benefit a business without ever touching the Internet.
First, Commerce can provide an easy way to register and track users on your site. If you have some reason users have to log in, such as a shareholder-only area for a public company, you can use Commerce to handle registration and access. Is it a bit heavy for that rather simple task? Consider the time you can save, especially if you want to log where users go so you can build a site better suited to their needs. You can also profile your users and target content directly to them. You can push almost all of the day-to-day campaign work out to relatively nontechnical users once IT sets up the underlying program.
(Personally, I hate sites that for reasons I can't fathom make me log in, so I urge you to be sure the benefits to your user outweigh the off-putting nature of such logins. On the other hand, I'm happy to log in to, say, The New York Times in order to read the paper on line; the benefit to me in this case is obvious. And targeting should offer advantages to the user, please, not just popup ads! Just my opinion, of course.)
Second, Commerce offers an easy way to manage direct-mail campaigns in house, using a great workflow engine called the pipeline. Commerce comes with a DM pipeline you can easily set up to fit your particular needs.
Third, it's easy to create a product catalog using Commerce. This is valuable even if you don't sell a bunch of parts over the Internet. What about parts used internally? (Think back to the STY example above; having worked on a tracking system for a company not unlike STY, I know how incredibly many parts are involved.) How many forms does your company use, and how often can end-users find the right one?
Finally, it's easy to integrate Commerce with your ERP system; you don't need to create more data islands.
Commerce Server integrates naturally in the
Internal_Or_External_It_Makes_No_Differ
Data Sharing (or, BizTalk as Babel Fish)
The late Douglas Adams envisioned the Babel fish, in The Hitchhiker's Guide to the Galaxy, as a universal translator. BizTalk Server can play a similar role in the data center.
It's hard to find a Babel fish, but if you do happen across one, just put it in your ear and it will start working. BizTalk's easier to find, if slightly harder to use. It's sure easier than hand-coding data translators, however (I made a good living a dozen years ago doing that). It's highly resilient with respect to changes in data schemas; obviously, major conceptual schema changes may hit you, but the XML architecture allows you to glide over most of the day-to-day tinkering that inevitably goes on.
I can't say enough about BizTalk Server as a bridge among all those islands of data in our systems. Let me just suggest some possibilities that might help a business:
* Build document maps that allow apps and business partners who use different document definitions to communicate without adopting a common database. This also works for internal groups using different systems and unable to come to agreement on a common worldview... even though we know this standoff never really happens, right? Most importantly, these BizTalk-based systems are easily modified when schemas (yours or theirs) change. As I noted last time out, BizTalk works well with and can supplement an existing EDI solution.
* Transfer data among systems during a merger or acquisition. IT only has the second-hardest job in M merging the cultures is even harder than merging the data. Still, data migration is quite painful. You can use BizTalk to run parallel systems as you work through changeovers, or to consolidate data while still providing service to at least some of the systems of the taken-over company.
* Manage business processes, even those that span days or weeks but must result in true (ACID) transactions. BizTalk even has connectors for MQ Series and CICS.
A four-month-trial version of BizTalk Server 2002 is available on line. You have to register, but you get something besides popup ads for doing so.
Programming.NET
Visual Studio
Snacks.NET
The folks at TechNet have been bugging me to mention this internal app. Microsoft has the reputation -- deserved -- for having meetings with food supplied. Lots of food. More food than attendees, to ensure everyone gets fed. And thus -- leftovers.
Lots of leftovers. And they often go uneaten even by our programmers-cum-scavengers, because no one knows the leftovers are in one of our kitchens.
Until now.
Some of our documentation folks decided that they could do more than write about
Okay, here's the real point -- they built this extremely rapidly. And most of the functions/services were reached with only a few lines of code. Here's what the developer wrote to me (with a bit of Micro-speak edited out):
We had a meeting a few months ago about the RADness of Visual Basic. The Program Manager said that VB programmers only wanted to write two lines of code to get something done. So I analyzed our application against this goal. The Web application (the Snax web site) did pretty well in being able to meet that goal. Even on the Web service most methods have 10 or fewer lines of code.
The Program Manager may have been joking about VB developers and two lines of code, but as an IT guy that's a terrific standard. Keep it simple, avoid the fancy/cute stuff, and you have a fighting chance of maintaining the code without needing lifetime job security for the programmer who wrote it. I'll try to post the Snax code by the time this article is published so you can see for yourself.
And yes, there's a small kitchen on pretty much every floor here, complete with the fabled free sodas. Through these kitchens, you can follow the graying of Microsoft. When I started, Jolt Cola was big; nowadays, it's Diet Coke/Pepsi without caffeine.
Conclusion
Would you believe this three-part series -- the three longest Editor's Notes I've written -- started out as a sidebar to another Note where I was just going to define
I couldn't find anyone else taking a deep IT perspective on
I think
If we in IT are more agile, our companies will be more agile, and more successful. The dotcom boom is over; in the business world, profit again matters. I think
I really do enjoy reading your comments and thoughts, though I can't respond to all of them; feel free to write me about this series, or about whatever's on your mind about TechNet or IT.
Or you can see an Evil Plan. I'm usually skeptical of Microsoft conspiracy theories, but for once its moderately plausible. Any real Java compatibility (like a Java VM implemented on top of the .NET VM) just wouldn't do. Can't create a two-way migration path!
So you create a new Java-like language that compiles to .NET byte codes. This makes it easy to port existing Java software to .NET. But it's a one-way path, because nobody will use this language to create new .NET software. If they like Java-like languages, they'll use C#. Otherwise they'll use C++ or one of the other .NET-compatible compilers.
Uhm, maybe not. If they just want to seduce Java programmers, they could just write a Java-to-C# translater. The languages aren't that different.
Oh well, what do I know?
Think .NET as a set of library that is already created for you. So when you use J#, you can use these API calls in .NET. Of course for many of the methods, you can find Java equivalent, but there are some you will have to code for yourself. For example, if you need to access the Windows registry, there is no standard way in the JDK. In addition, if you create a control in another language say Perl.NET, you are able to use it in J#.
That's the most stupid name I've ever heard.
Even though I'm an avid C fan, I cannot but wonder what this topic has to do with Java: it is not running on a Java virtual machine, and since it will only run on .NET, it is per definition not cross platform.
Knowing Micro$oft, the syntax will not even be compliant with Java.
So what the heck is J# to do with Java and what is the coffee cup doing in the story?
/me votes for a specific topic "M$ FUD and misguiding (aka new monopoly) schemes"
Genius doesn't work on an assembly line basis. You can't simply say, "Today I will be brilliant."
Microsoft said back in the late 80's they would port COM to Unix... I'm still waiting. Microsoft says a lot of things. Don't you get it?
Despite the average bias here against Microsoft, the whole .NET thing could be a great thing if/when Mono and other projects come out for more support. The biggest feature I see for J# comes with speed. The Java VM for Linux & Windows is horribly slow, only the Mac OS X VM is anywhere near a full program. From all the tests I've done comparing C# and Java, C# apps have blown Java out of the water in speed. Microsoft simply did a better VM implementation than Sun. If this means my Java apps will run fast on Windows machines, and with a standard UI set (instead of the ugly Swing or almost-implemented-ok AWT), then more power to them. Sun got complacent with their VMs, hopefully this will force them to spend more time flushing out Java... Prolly not though...
I understood that companies had written software in J# and were upset that J# was going to die. J# is for them.
C# is so closely related to Java, that there is no need for J#. MS has already started up marketing to get Java developers to try C#. I am a Java developer, and if I was forced to use a .NET language, I'd chose C#. J# just seems like a redundant language. It makes no sense.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
"almost-implemented-ok AWT"?
Are you serious?
Bill, your skirts are showing.
668: Neighbour of the Beast
Wrong.
The definition of "open source" includes several important points beyond simpy allowing people to see the code. Microsoft's insulting "Shared Source" license fails several of these points.
Most notable is free redistribution. As the OSI puts it:
Other notable trouble points with MS "shared source" include the OSI conditions of no discrimination against persons or groups and non-restriction of other software.
The .NET framework provides a set of classes and wraps the Win32 API (and other APIs) where necessary.
It's my understanding that Microsoft isn't trying to push J# as a new platform, but rather to support small existing J++ users to migrate to .Net.
Now that I've viewed this using an industry-standard microsoft browser I finally understand the genius involved.
J# isn't meant to run on a JVM. It's just one of the .Net family of languages.
.Net languages are compiled to the same "bytecode" that MS calls MSIL. J# is no exception. It is compiled to MSIL, not to Java bytecode.
.Net framework in a thing called the "common language runtime", which is similar to a JVM, but designed from the start to *try* to accommodate as wide a range of source languages as possible.
.Net doesn't limit you to doing everything in a single language. (However, it *does* currently limit you to Windows only, quite unlike Java, but that's changing quickly.
.Net applications. When Ximian's Mono Project is fully up and running (Go Mono!), the MSIL output from J# will become executable on a Linux box. When that happens, a Java programmer who wants to deploy on Linux will suddenly have two excellent class frameworks to choose from: the Java standard and .Net.
All
Whether you prefer to write your source in Java (using J#), or C#, or VB.Net, or Perl.Net, or whatever, the source gets compiled to the same MSIL.
The MSIL code then runs on the
After they become MSIL, they are completely interchangable, regardless of their original source language. You could grab a cool C# utility class off the Web somewhere and use Java "extends" to write a subclass in Java. If you find it easier to parse text with Perl than with Java (who doesn't?), then you could write just the text parser classes in your Java app in Perl.Net.
The idea is that you get to work in a source language that you choose. Unlike the Java world,
The point of J# is to let Java lovers use Java to create
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
Before anyone starts bashing J# to say that it should have never been created and M$ is the anti-christ and bla bla bla.. There are a few good reasons. No matter what you may think, people will accually program in .net. It's not that bad. It's accually a HUGE improvement to programming RAD apps in windows. The best RAD development for windows prior to this was VB or Delphi, and I Think C# is a good compromise between C++, Java, and VB. They tried to capture the syntax of java with the flexibility of c++ and the RAD capabilities of VB. In general it was a good idea. The reason having J# is such a good thing is i can now take the code i've already written for java, put it in a project and compile it as a windows dll. Lets say I wrote an extensive library for software in Java and wanted to port it to a windows app i'm working on a year+ down the line, then it will come in real handy.
What microsoft fails to realize is that the idea of coding in J# by itself is ludicrus because The whole point of Java is it's ALREADY cross platform, and just like .NET it runs on VM. J# is for those people who have already coded in java and want to use it in a windows only project. If you just read between the lines it's Microsoft's sleezy way to try and bring more attention to Windows and .NET in general. More a convience and marketing ploy than anything people will pratically use.
Worst case you could just not learn C# in general and write it all in Java, but this is mixing java and the .NET framework, which i'd rather keep separate.
- tristan
...some people aren't as flexible as you are when it comes to languages.
.Net and Java when using, well, Java.
.Net (the convenience depending on how much they rely on the Java class libs).
I'm with you. I think C# is Java-done-better (referring to the source languages only). It has all kinds of improvements over Java that many of us Java programmers have been asking for for years. I intend to use C# when using
But a lot of people learned Java as their first and only language and will drag their heels or spout sanctimonious anti-.Net rhetoric based on little more than a secret fear of having to leave the Java nest.
J# will help people like this (after they get comfy with J#, they'll be much closer to C#), it will help users of the old J++, and it may make it a bit easier to port various useful Java utilities over to
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
It's not necessary for MS to create .Net for other platforms. We're not at the mercy of MS.
.Net support and can't get it from MS, they'll get a huge headstart from the LGPL'ed Mono code.
Even Java gets support for most of its many platforms from entities other than Sun.
.Net on Linux is already well on it's way. It's called theMono Project by Ximian, the same people who created Gnome. If developers on other platforms want to have
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
It's that simple.
MSIL and common runtime dont have a chance of running level 5, and probably even level 4 languages.
.NET to cut into the "write once, run everywhere" market, and to try to replace ALL languages with the .NET family.
Lisp and Prolog will never compile to MS's "standards".
MS created
MS has funneled all this money and effort in the attempt to force all developers to write for MS platforms.
Anything else, and MS wont get every cent available.
Java 1.4 is faster than Perl be leaps and bounds!
Pretty soon, it'll be comparable to c++
As for C#'s "speed", thats from MS's hidden APIs
Any Java apps compiled for C# will be horribly inefficient, as computers can't port code nearly as well and humans.
We'd all be emailing out SS #s and Credit Card #s to MS to "save us the time".
Comparing everything to 1 or 2 people is like saying "the unabomber was bad, so all people named 'ted' are bad!"