What is the future of JAVA ?
JAVA was overcoming Microsoft's .net because of it's platform independence.
As in coming couple of years , Microsoft is going to launch a version of .net that will support all platforms like windows, unix, linux etc.
Then will .net become trouble for JAVA in future ?
Please Reply.
well i dont really think that Microsoft can even think of putting JAVA in any kind of troubles.
Interoperabilty and PlateformIndipence are not the only features of JAVA that excells it from .net, but its Excells in every other feature. like J2EE architecture is far more relieble then .net Framework Architecture.. other then that J2ME is used every where in the world, instread of MS mobile kit
so no worries
the time MS wiill achieve Plateform Indepence Java will be far Ahead
As in coming couple of years , Microsoft is going to launch a version of .net that will support all platforms like windows, unix, linux etc.
It basically exists already (mono)
hmm, we're going to have a weekly "Jav iz ded" thread here as well?
Was kinda missing it, every other Java related site has one and has had one for as long as Java has been in existence.
It basically exists already (mono)
Mono has still many problems to over come...
What is the future of JAVA ?
JAVA was overcoming Microsoft's .net because of it's platform independence.
As in coming couple of years , Microsoft is going to launch a version of .net that will support all platforms like windows, unix, linux etc.
Then will .net become trouble for JAVA in future ?
Please Reply.
/yawn
Hasn't this been hashed out over and over enough? It's really quite tired and you don't have any unique points of insight.
didnt microsoft already bootleg it? like they killed c++ with c# (Which sucks) And then the made like j++ and got sued over it or something. is there any chance (no) that j++ could take over java?
nope, you're wrong on both counts.
C# didn't "kill" C++, and J++ was no replacement for Java. J++ was Java with a custom user interface library.
J++ was created under the terms of the license agreement Sun had granted Microsoft at the time, and fell within that license agreement.
Several years later, when it turned out Microsoft's WFC library was more popular with users than was Sun's AWT, Sun changed the license agreement to disallow the creation of user interface libraries that aren't platform independent and immediately sued Microsoft for infringing on those new terms. This was at the height of the anti-Microsoft craze, so it was easy for them to find a judge who would find in their favour, and they did.
C# will not replace c++ . They are totally different languages.
I don't think that Java is going to disappear completely, but I think that the future of software applications in general will be server based with browsers as thin clients. This mean that the GUI stuff will probably fall into disuse.
This is more for business reasons than programming reasons. And the future will be dictated by what makes the most profit for entrepreneurs, not what makes programmers happy.
From a business standpoint, server side applications are far easier to maintain, and application usage is easier to control and get paid for.
Hoppy
you're several years behind the times Hoppy.
The "everything is a web application" hype is already declining, with ever more people realising that web applications are not the way forward for a "rich user experience".
As a result, we're again in an upswing towards fat clients talking to relatively lean servers, a similar concept to that employed in the client/server architectures of the 1980s and '90s.
It's all cyclical really. From the fat server with thin terminals (mainframe/terminal, webapplication/browser) to client/server (webapp/RIA), to standalone applications (though that's unlikely to be much of a factor in the future).
We've seen it all before, we'll see it all again.
I said the webbrowser as an application hype would not last years ago, and I seem to be proven right.
It's not relevant what the current trend happens to be at any given moment in time. The fact is that what I said about the maintenance, usage control, packaging and distribution costs to companies that produce applications are significantly lower with a server based application than with a fat client apps. That will eventually rule the day.
Hoppy
You are quite right. But it doesn't matter whether the client is a browser or a thin app that just looks (to the server) like a browser. I still think that, in the future, the fat part of the app is going to reside on the server.
My point was that just as a river does not travel directly to the sea, it meanders turning left, then right, then left again. It's goal is the point of lowest altitude, the sea. So the path of software development will travel. Its ultimate goal will be the point of greatest economic benefit. That of lowest cost.
Which doesn't mean that user interface technology will be unimportant, as was claimed.
And no, there will be a trend to offload server functionality back to the client. Part of that will be "performance" (clients don't want to wait for server roundtrips for everything, they're tired of it already), part security (yes I know, the current "wisdom" is to do nothing on the client but the reasoning will be to have the client do validation and stuff so no corrupt data even reaches the server), part of it reduction in server load (why have the server do all those non-critical tasks, taking up most of its CPU load when server hardware is harder to upgrade than desktop hardware).
There are more reasons, and indeed we've heard them all before (as well as their exact opposites to favour pure server based systems).
It may be counter to your way of thinking, but it will all happen.
I've been myself involved in operations that decentralised mainframe systems to smaller branch servers.
I've also (at roughly the same time) been involved in operations that centralised branch servers to mainframes.
Both type of projects used the same style of reasoning, with exact opposites of the actual arguments, and both were right.
It's the same with server and desktop systems. There's no right or wrong, only shades of grey and personal opinions.
don't worry my friend it will take plenty of time to out-do a technology that is continously evolving since 10 years. no threat as long as compatability, extensibility and productivity are taken care of. And consider the java community, now do u think any technology has that much of scope and time to equal java in terms of serious business.
Which doesn't mean that user interface technology will be unimportant, as was claimed.
And no, there will be a trend to offload server functionality back to the client. Part of that will be "performance" (clients don't want to wait for server roundtrips for everything, they're tired of it already), part security (yes I know, the current "wisdom" is to do nothing on the client but the reasoning will be to have the client do validation and stuff so no corrupt data even reaches the server), part of it reduction in server load (why have the server do all those non-critical tasks, taking up most of its CPU load when server hardware is harder to upgrade than desktop hardware).
There are more reasons, and indeed we've heard them all before (as well as their exact opposites to favour pure server based systems).It may be counter to your way of thinking, but it will all happen.
I've been myself involved in operations that decentralised mainframe systems to smaller branch servers.
I've also (at roughly the same time) been involved in operations that centralised branch servers to mainframes.
Both type of projects used the same style of reasoning, with exact opposites of the actual arguments, and both were right.It's the same with server and desktop systems. There's no right or wrong, only shades of grey and personal opinions.
I think you're wrong on the performance issue. Technologies like ASP.NET that enable sophisticated server based data validation without reloading the entire browser page combined with advances in hardware performance that have sped up both client, server and everything in between (broadband data transmission) continue to improve performance year after year.
I take issue with your statement that that server hardware is harder to upgrade than desktop hardware. I don't have statististics to prove it, but my instinct tells me that the cost to upgrade a server is far less that the cost to upgrade all of the clients it serves.
I will admit that it makes sense to have some basic data validation on the client side, and this is the norm for most internet apps. I also admit that it makes sense to have functionality on the client side. But if the logic to achieve that functionalify (Javascripts and what not) comes from and is maintained on the server, then the provider of the software does not have to have multiple teams of programmers and customer support staff to maintain multiple versions of the product as is the case with shrink-wrapped desktop apps. Furthermore, there is no packaging cost and no distribution cost as there is with desktop apps.
Actually, I think that we agree more than we disagree. From the standpoint of what functionality is best executed on the server and what functionality is best executed on the client side, I don't think that it can be solved with a blanket generalization. I think that it is a judgement that depends on the nature of the particular application.
That having been said, the original issue was, if I can even remember back that far, if Java was going to go away. My answer is no, but I think that it belongs on the server. I think that it is a clean, powerful language the frees the programmer, to a large extent, from the burden of memory management and resource management and after a while (maybe in 10 years time) you will not find a JRE on very many desktop computers.
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.