Linux programmers aren't Java programmers, that's why. Java programmers aren't bound to any O/S!:)
Ditto for Mono programmers.
But seriously, in any discussion we need to segragage the language, from the class libarary framework, from the runtime platform from the operating system.
Java, C#, VB.NET etc. are languages, which are largely similar. Some developers love features of one of these over the other..NET Framework, Mono, J2x# etc. are class library frameworks which are all extremely useful in their own rights and limited in their own ways.
CLR, Mono Runtime, JVM, J2EE app server etc. are the runtime platforms
Windows, Linux, Solaris etc. are the OS.
So, a Linux programmer, namely one whose job it is to write Linux programs is more likely to write in a language that is suited for Linux, say 'C', or if they prefer to move up the stack, and write it to run on a linux compatible runtime like JVM or Mono, then they'll be bound to the language and frameworks for that runtime, right?
Bottom line: There are choices -- plenty of choices, and that's a good thing.
Finally -- there is an alternative, that allows you to unify the stack at the framework level down, giving you the most flexible choice -- and that is from Mainsoft (disclosure: I love their product so much I applied to work for them, and they accepted) -- and called Visual MainWin for J2EE with a developer edition called Grasshopper.
What does it do? Allow you to virtualize all of this by unifying the.NET and Java stack through Mono. You can use VS.NET to code in.NET, compile to Java and run on Linux. It's a beautiful thing....
I'm not sure about 'more' or 'less' suitable, but when building enterprise apps, there's lots of app infrastructure that usually needs to be built, for threading, scaling, security, management etc. J2EE implements a bunch of that for you on an app server if you build your app as EJBs (in particular) for that app server. So many companies opt to buy, and not build, that infrastructure (smart choice) and not go with.NET for large scale enterprise apps.
It's not that Java is better than.NET for enterprise apps, its just that there are cheap app servers available that will save you tonnes of $$$ in dev costs.
Most of the time I've seen modelling tools used (like Rational Rose etc.) has either been on a job interview, or after the fact. You know, app is built, ready to be deployed, and to keep ops or CTO happy you need a well modelled architecture:)
The real productivity is IDE based. I've worked with large and diverse groups, and the winner in IDE productivity, for the 'average' developer, has been hands down VS.NET. Followed by Weblogic Workshop and Oracle JDeveloper.
That is what is so attractive about this product from Mainsoft. You can get your 'morts' to build apps that run on J2EE, taking advantage of this superior runtime platform, without training them for J2EE. Huge productivity boost. And with all the jobs that are being outsourced to India and the rest of the far east, productivity gains by domestic workers cannot be a bad thing, can it?
I am inclined to disagree. A large IT shop that has the 'problem' of needing to move business logic and/or web applications to the J2EE platform would evaluate *all* possible solutions. They're a large shop, so they have the resources to do an 'elaboration' stage in every project.
The process is generally to have 2 or 3 techie people go out and find potential solutions and then have a 'bake-off' to put them through their paces, and size the effort and costs accordingly.
This Grasshopper thing is a totally new and innovative way of solving the problem. It may not be for everyone, but if someone were to dismiss it because it is a byte code conversion, and that is a 'bad' thing, then they simply are not doing their job properly.
I have found, from extensive experience in designing and building Enterprise-level applications for 5 digit uptime that the best design is to have extremely granular functionality. Small, lean apps, services etc. I would estimate that 75%-90% of these use only the.NET namespaces that Grasshopper supports, so a port of them to Linux is a home run. The rest may require some tweaking.
The process to follow should be to port the easy ones first (in a lab, and not a production environment), and make sure they interop with the non-ported ones (SOAP is a beautiful thing), and then stress test the ported ones for their runtime characteristics.
You would be surprised at the results.
Hands up how many of you work for large Enterprises? (You know the ones that are the bread and butter of the technology companies)
Ok. Now, how many of you have mixed deployments? You know, Wintels running pre.NET application, Wintels running.NET applications and App Servers of Some ilk running Java and J2EE applications on various operating systems. And some poor sods (probably you) trying to hold it all together?
Ok. Good. Now, I'm not sure how many still have their hands up, but in my travels I have encountered *lots* of Enterprises with such data centers.
Ok, now, how many of you are development managers? Probably not so many. Well, I have been one, and I have known many, and I can say with almost 100% certainty that those who managed groups of junior to mid level devs, building web applications using VS.NET finished more projects, on time and under budget than those that didn't. Fact. You might think that 'real' developers don't use IDE's, and I applaud you that don't, but the fact is the majority of developers who get paid to program do use IDE's and without doubt the most productive ones have been using VS.NET and its predeccessors. Lots of people love Eclipse et al, but, show me a person who can write 500 function points a month in Eclipse and I will show you a VS.NET who can be equally productive, but cost the employer half as much.
Sure J2EE runtime characteristics are *much* better than the.NET framework ones. But to bean counters that doesn't mean squat.
So now, these guys, Mainsoft come up with a way to have those same junior developers run the same applications, in many cases without modification, on the J2EE platform.
And this is a bad thing?
And once it is on J2EE, it can run on Linux too.
And this is a bad thing?
Skepticism is healthy, but only if tempered by fact. For you guys who are knocking this, do yourself a favor -- download it and try it out. It's great.
Now if only they supported the Windows Forms workspace, then I could look at migrating client apps as well as web apps and web services....surely there is no better way of migrating that using something like this? Despite the similarities between C# and Java on the surface, the language isn't as important as the class libraries that support that language. Not all.NET namespaces are implemented in Java by mainsoft, but the majority of the ones for Web Applications and Web Services seem to be. That makes this a real winner in my book.
I reviewed this product for devx.com some time ago (a previous version of the product), and have to say I found the experience VERY positive, in particular the facility to consume EJBs in.NET web applictions with the same simplicity, using proxies, that you can consume Web Services.
http://www.devx.com/dotnet/Article/20540/0 http://www.devx.com/dotnet/Article/20866/0
Thumbs way up!
Laurence
Slashdot Mirror
Linux programmers aren't Java programmers, that's why. Java programmers aren't bound to any O/S! :)
Ditto for Mono programmers.
But seriously, in any discussion we need to segragage the language, from the class libarary framework, from the runtime platform from the operating system.
Java, C#, VB.NET etc. are languages, which are largely similar. Some developers love features of one of these over the other. .NET Framework, Mono, J2x# etc. are class library frameworks which are all extremely useful in their own rights and limited in their own ways.
CLR, Mono Runtime, JVM, J2EE app server etc. are the runtime platforms
Windows, Linux, Solaris etc. are the OS.
So, a Linux programmer, namely one whose job it is to write Linux programs is more likely to write in a language that is suited for Linux, say 'C', or if they prefer to move up the stack, and write it to run on a linux compatible runtime like JVM or Mono, then they'll be bound to the language and frameworks for that runtime, right?
Bottom line: There are choices -- plenty of choices, and that's a good thing.
Finally -- there is an alternative, that allows you to unify the stack at the framework level down, giving you the most flexible choice -- and that is from Mainsoft (disclosure: I love their product so much I applied to work for them, and they accepted) -- and called Visual MainWin for J2EE with a developer edition called Grasshopper.
What does it do? Allow you to virtualize all of this by unifying the .NET and Java stack through Mono. You can use VS.NET to code in .NET, compile to Java and run on Linux. It's a beautiful thing....
I'm not sure about 'more' or 'less' suitable, but when building enterprise apps, there's lots of app infrastructure that usually needs to be built, for threading, scaling, security, management etc. J2EE implements a bunch of that for you on an app server if you build your app as EJBs (in particular) for that app server. So many companies opt to buy, and not build, that infrastructure (smart choice) and not go with .NET for large scale enterprise apps.
It's not that Java is better than .NET for enterprise apps, its just that there are cheap app servers available that will save you tonnes of $$$ in dev costs.
Amen to that.
:)
Most of the time I've seen modelling tools used (like Rational Rose etc.) has either been on a job interview, or after the fact. You know, app is built, ready to be deployed, and to keep ops or CTO happy you need a well modelled architecture
The real productivity is IDE based. I've worked with large and diverse groups, and the winner in IDE productivity, for the 'average' developer, has been hands down VS.NET. Followed by Weblogic Workshop and Oracle JDeveloper.
That is what is so attractive about this product from Mainsoft. You can get your 'morts' to build apps that run on J2EE, taking advantage of this superior runtime platform, without training them for J2EE. Huge productivity boost. And with all the jobs that are being outsourced to India and the rest of the far east, productivity gains by domestic workers cannot be a bad thing, can it?
Laurence
I am inclined to disagree. A large IT shop that has the 'problem' of needing to move business logic and/or web applications to the J2EE platform would evaluate *all* possible solutions. They're a large shop, so they have the resources to do an 'elaboration' stage in every project. The process is generally to have 2 or 3 techie people go out and find potential solutions and then have a 'bake-off' to put them through their paces, and size the effort and costs accordingly. This Grasshopper thing is a totally new and innovative way of solving the problem. It may not be for everyone, but if someone were to dismiss it because it is a byte code conversion, and that is a 'bad' thing, then they simply are not doing their job properly. I have found, from extensive experience in designing and building Enterprise-level applications for 5 digit uptime that the best design is to have extremely granular functionality. Small, lean apps, services etc. I would estimate that 75%-90% of these use only the .NET namespaces that Grasshopper supports, so a port of them to Linux is a home run. The rest may require some tweaking.
The process to follow should be to port the easy ones first (in a lab, and not a production environment), and make sure they interop with the non-ported ones (SOAP is a beautiful thing), and then stress test the ported ones for their runtime characteristics.
You would be surprised at the results.
Hands up how many of you work for large Enterprises? (You know the ones that are the bread and butter of the technology companies) .NET application, Wintels running .NET applications and App Servers of Some ilk running Java and J2EE applications on various operating systems. And some poor sods (probably you) trying to hold it all together?
.NET framework ones. But to bean counters that doesn't mean squat.
.NET namespaces are implemented in Java by mainsoft, but the majority of the ones for Web Applications and Web Services seem to be. That makes this a real winner in my book.
.NET web applictions with the same simplicity, using proxies, that you can consume Web Services.
Ok. Now, how many of you have mixed deployments? You know, Wintels running pre
Ok. Good. Now, I'm not sure how many still have their hands up, but in my travels I have encountered *lots* of Enterprises with such data centers.
Ok, now, how many of you are development managers? Probably not so many. Well, I have been one, and I have known many, and I can say with almost 100% certainty that those who managed groups of junior to mid level devs, building web applications using VS.NET finished more projects, on time and under budget than those that didn't. Fact. You might think that 'real' developers don't use IDE's, and I applaud you that don't, but the fact is the majority of developers who get paid to program do use IDE's and without doubt the most productive ones have been using VS.NET and its predeccessors. Lots of people love Eclipse et al, but, show me a person who can write 500 function points a month in Eclipse and I will show you a VS.NET who can be equally productive, but cost the employer half as much.
Sure J2EE runtime characteristics are *much* better than the
So now, these guys, Mainsoft come up with a way to have those same junior developers run the same applications, in many cases without modification, on the J2EE platform.
And this is a bad thing?
And once it is on J2EE, it can run on Linux too.
And this is a bad thing?
Skepticism is healthy, but only if tempered by fact. For you guys who are knocking this, do yourself a favor -- download it and try it out. It's great.
Now if only they supported the Windows Forms workspace, then I could look at migrating client apps as well as web apps and web services....surely there is no better way of migrating that using something like this? Despite the similarities between C# and Java on the surface, the language isn't as important as the class libraries that support that language. Not all
I reviewed this product for devx.com some time ago (a previous version of the product), and have to say I found the experience VERY positive, in particular the facility to consume EJBs in
http://www.devx.com/dotnet/Article/20540/0
http://www.devx.com/dotnet/Article/20866/0
Thumbs way up!
Laurence