Apache loses Java showdown vote to Oracle(theregister.co.uk)
theregister.co.uk
Apache loses Java showdown vote to Oracle
http://www.theregister.co.uk/2010/12/07/apache_google_vote_no_oracle_roadmap/
12 comments
As a long time Java developer (I downloaded the first beta that was released). I would have to say that this pretty much did it for Java. Sure it was showing it's age but until now the pain of leaving it behind was too great for many. I think now there are a lot of people wondering what the future pains will be brought if one decides to stay in the Java world. Oracle has thrown the gauntlet down and pretty much said, Java is for paying customers. So my question now is who is the likely successor? I have been playing the guessing game for a while now as to who I think the most likely champion is and I keep drawing blanks. I think the JVM languages are too close to Oracles reach for comfort now, so I think Clojure, Scala, JRuby and the rest are out. Python is nice and has a pretty decent eco-system but there is a die hard no interpreted languages camp (I know, I know) but it exists. I don't know enough about Go to form an opinion of it's worthiness. I don't think we are going back to C or C++. Objective-C is perceived to be too Apple, .NET too Microsoft. Perl had it's moment in the sun. Ruby too controlled by a select few. My point is, I would love to know what other people think on the subject. I think the writing is on the wall, I just can't seem to read what name the writing spells.
I think .Net is poised to capture much of Java's current market. The C# developers I know really do seem to enjoy the language and associated tooling, and it's very well established in the enterprise. I can't think of anything else that has significant mindshare and is directly addressing that space.
At the same time, alternative languages (Python, Ruby, etc.) are becoming more and more capable, and are slowly eroding the class of problems that need "enterprise-grade" solutions. Furthermore, virtualization, as well as tools like Chef, Puppet, Capistrano, Virtualenv, and RVM are making great strides at simplifying the deployment and management of "native" solutions.
Taken together, I think you'll see huge gains by smaller languages in the areas traditionally served by Java and .Net.
But if I had to pick a dark horse or two, I'd look to LLVM and JavaScript. There's huge amount of momentum and money behind LLVM, and I could easily see it becoming the next major target platform for experimental languages. Similarly, the recent JavaScript arms race has left us with at least four extremely high-performance JavaScript runtimes, and it's quickly becoming the lingua franca of the web. There have been many attempts to harness that talent and apply it to more general application development: Apple's Dashboard, Palm's WebOS, Node.JS, Appcelerator Titanium. Others initiatives are trying to pull general application development into the web dev world: Sproutcore, 280 North's Cappuccino, etc. Eventually, someone is going to strike the right balance, and JavaScript's importance and influence will skyrocket.
Other things that may spawn something really cool: Parrot, Go.
At the same time, alternative languages (Python, Ruby, etc.) are becoming more and more capable, and are slowly eroding the class of problems that need "enterprise-grade" solutions. Furthermore, virtualization, as well as tools like Chef, Puppet, Capistrano, Virtualenv, and RVM are making great strides at simplifying the deployment and management of "native" solutions.
Taken together, I think you'll see huge gains by smaller languages in the areas traditionally served by Java and .Net.
But if I had to pick a dark horse or two, I'd look to LLVM and JavaScript. There's huge amount of momentum and money behind LLVM, and I could easily see it becoming the next major target platform for experimental languages. Similarly, the recent JavaScript arms race has left us with at least four extremely high-performance JavaScript runtimes, and it's quickly becoming the lingua franca of the web. There have been many attempts to harness that talent and apply it to more general application development: Apple's Dashboard, Palm's WebOS, Node.JS, Appcelerator Titanium. Others initiatives are trying to pull general application development into the web dev world: Sproutcore, 280 North's Cappuccino, etc. Eventually, someone is going to strike the right balance, and JavaScript's importance and influence will skyrocket.
Other things that may spawn something really cool: Parrot, Go.
>I think .Net is poised to capture much of Java's current market.
Anyone leaving Java because of Oracle is not going to .Net.
> The C# developers I know really do seem to enjoy the language and associated tooling, and it's very well established in the enterprise.
Doesn't matter. If you are leaving Java because of Oracle, then you don't care about the tooling. Moving to .Net will just move you to another vendor those guys have spendt the last years moving away from.
Anyone leaving Java because of Oracle is not going to .Net.
> The C# developers I know really do seem to enjoy the language and associated tooling, and it's very well established in the enterprise.
Doesn't matter. If you are leaving Java because of Oracle, then you don't care about the tooling. Moving to .Net will just move you to another vendor those guys have spendt the last years moving away from.
Sadly, you can't say "anyone" here. I'm quite certain some people will find Microsoft more free than Oracle and, given the surface-level similarity between the two languages, will chose C# before they move on to a different language.
> I'm quite certain some people will find Microsoft more free than Oracle
After all, like professor Wirth once said, P. T. Barnum was right. It's not reasonable to bet your company on the premise either Microsoft or Oracle will have a sudden change of mind and start playing by the rules.
It's not reasonable to bet a dollar on that ludicrous idea.
After all, like professor Wirth once said, P. T. Barnum was right. It's not reasonable to bet your company on the premise either Microsoft or Oracle will have a sudden change of mind and start playing by the rules.
It's not reasonable to bet a dollar on that ludicrous idea.
>>I think .Net is poised to capture much of Java's current market.
> Anyone leaving Java because of Oracle is not going to .Net.
I agree that folks who abandon Java because of Oracle's presence are unlikely to embrace Microsoft, but that doesn't mean that .Net won't continue to erode Java's market share.
Specifically, consider the many shops that employ both Java and .Net. In those environments, I could see .Net's adoption accelerating due to the perception of strife within the Java community: James Gosling and Tim Bray both leaving Oracle, Jonathan Schwartz pitching litigation over Java patents as a revenue stream, the subsequent lawsuit against Google, the OpenSolaris and OpenOffice.org votes of no confidence and subsequent forks, Apache attempting to throw a wrench into the JCP... that's not the picture of a healthy ecosystem.
So it's not that the enterprises will see Oracle and flee, but that they'll see the turmoil and litigation, reason that C# and Java are similar enough, and opt for the more peaceful of the two, at least for new development.
> Anyone leaving Java because of Oracle is not going to .Net.
I agree that folks who abandon Java because of Oracle's presence are unlikely to embrace Microsoft, but that doesn't mean that .Net won't continue to erode Java's market share.
Specifically, consider the many shops that employ both Java and .Net. In those environments, I could see .Net's adoption accelerating due to the perception of strife within the Java community: James Gosling and Tim Bray both leaving Oracle, Jonathan Schwartz pitching litigation over Java patents as a revenue stream, the subsequent lawsuit against Google, the OpenSolaris and OpenOffice.org votes of no confidence and subsequent forks, Apache attempting to throw a wrench into the JCP... that's not the picture of a healthy ecosystem.
So it's not that the enterprises will see Oracle and flee, but that they'll see the turmoil and litigation, reason that C# and Java are similar enough, and opt for the more peaceful of the two, at least for new development.
While I love JavaScript, I shudder at the though of using it as a systems integration language. For the verry reason that it shines as a UI development language (flexibility), it makes me cringe to think of using it for system integration work where items like guaranteed delivery and transactions are far more important that flexibility. As well, I just don't see .NET doing it, it has very little adoption amount the unix camps and the next language will most assuredly will come with the blessing of that camp just as Java did. I mean it was the unix guys that adopted it because they could offer there server offerings on their platform of choice while not ignoring the Microsoft juggernaut.
As for LLVM, I have had the same thought and I think you are on to something, I keep thinking whatever it is, it will crop up on LLVM.
As for LLVM, I have had the same thought and I think you are on to something, I keep thinking whatever it is, it will crop up on LLVM.
More than that, for typical distributed "enterprise-y" type stuff (a crap-ton of services that call each other) MS's stuff is generally superior. Creating a typical WSDL based service on Java using Spring requires a lot more work than with .Net, and all of the nice little features (like tools for manually calling a web-service API) are built-in.
Unless you are a big enough company to be able to roll your own infrastructure tools to make use of linux's advantages or have very significant scale requirements the cost difference is unlikely to be huge (much of the cost will be operations labor anyway) and the service and support backing of MS is a significant boon in the enterprise world.
LLVM and Javascript are contenders but they aren't platforms yet, although I think they will see a ton of use in web apps and web services, especially outside the enterprise.
Unless you are a big enough company to be able to roll your own infrastructure tools to make use of linux's advantages or have very significant scale requirements the cost difference is unlikely to be huge (much of the cost will be operations labor anyway) and the service and support backing of MS is a significant boon in the enterprise world.
LLVM and Javascript are contenders but they aren't platforms yet, although I think they will see a ton of use in web apps and web services, especially outside the enterprise.
Bullshit. I work at a .NET shop who had to interoperate with another company developing WSDL based webservice in Java. They could do a whole bunch of stuff that we weren't able to do because Visual Studio didn't support all the stuff that they could do with their open tools (case in point: field level encryption - supported in Visual Studio Pro 2005 but none of later versions of VS that we use)
I'll freely admit I have limited and dated experience of .NET use of WSDLs, but I remember it making me almost cry with frustration. Really, really grim.
I pretty much agree.
Java is under a two-pronged attack. LLVM is quickly becoming the preferred target platform. The harder Oracle is to work with the harder it will be for new languages to target the JVM.
Also Java's niche is getting squeezed from both ends. Python, Ruby, and Javascript can do more of what Java does with less hassle. Languages like Go and Rust are bridging the divide from C/C++ to Java also. Both languages have a nice mix of good performance, predictable performance, high-level semantics, and concurrency.
Java is under a two-pronged attack. LLVM is quickly becoming the preferred target platform. The harder Oracle is to work with the harder it will be for new languages to target the JVM.
Also Java's niche is getting squeezed from both ends. Python, Ruby, and Javascript can do more of what Java does with less hassle. Languages like Go and Rust are bridging the divide from C/C++ to Java also. Both languages have a nice mix of good performance, predictable performance, high-level semantics, and concurrency.
Well that's pretty simple. There isn't really a suitable successor that does what Java really does. It was low-enough level to have decent performance and high enough level to be used to quickly do some complex stuff with some runtime protection.
I'm curious, the JCP didn't exist until quite a while after Java got going. There are tons of documents in various states of completion and with various levels of support. To me, JCP has sort of given java a terrible look to the non-java coder. It looks fat, bloated and incredibly Byzantine. I've actually heard developers have conversations about JCP<number>, that just seems like a bad thing to me. Meanwhile SpringSource has done some great and wonderful things. Even newer JCP specs, like JPA (if that's 'newer') were sort of done outside of it all and then backported in to the JCP process.
I don't know, C has been pretty much "dead" for decades, there is very measured and limited change in that language. Putting the Java language in a similar place, adding some dynamic support to the JVM and maybe focusing on cleaning up the class libraries and interop with higher level languages might be the best thing for it.
I don't know, it all looks bad, that's for sure but i can't say the JCP was the end all be all either.
I'm curious, the JCP didn't exist until quite a while after Java got going. There are tons of documents in various states of completion and with various levels of support. To me, JCP has sort of given java a terrible look to the non-java coder. It looks fat, bloated and incredibly Byzantine. I've actually heard developers have conversations about JCP<number>, that just seems like a bad thing to me. Meanwhile SpringSource has done some great and wonderful things. Even newer JCP specs, like JPA (if that's 'newer') were sort of done outside of it all and then backported in to the JCP process.
I don't know, C has been pretty much "dead" for decades, there is very measured and limited change in that language. Putting the Java language in a similar place, adding some dynamic support to the JVM and maybe focusing on cleaning up the class libraries and interop with higher level languages might be the best thing for it.
I don't know, it all looks bad, that's for sure but i can't say the JCP was the end all be all either.
> There isn't really a suitable successor that does what Java really does. It was low-enough level to have decent performance and high enough level to be used to quickly do some complex stuff with some runtime protection.
There was such a successor before Java even existed: ML. It is safer, and current free implementations are at least as fast (and they have a C FFI). The catch is, programmers need to recognize that "OO" is little more than a brand, then see that despite it's "FP" branding, ML implements the underlying principles just as well (if not better).
There was such a successor before Java even existed: ML. It is safer, and current free implementations are at least as fast (and they have a C FFI). The catch is, programmers need to recognize that "OO" is little more than a brand, then see that despite it's "FP" branding, ML implements the underlying principles just as well (if not better).
Unfortunately, what Java really does isn't only to be that combination of low-level and high-level. Just as vitally, (1) it is nice and easy and familiar for programmers familiar with current mainstream languages -- C-family syntax, approximately the usual control structures, few concepts that someone who's already programmed in C or C++ or C# or whatever won't find reasonably familiar -- and (2) it comes with a big bag of libraries for doing standard things: UI, database connectivity, regular expressions, logging, XML processing, and so forth.
Yes, ML is pretty good at those underlying principles; yes, you can use it to write code that's compact, safe, and fast; but it's not going to replace Java because #1 and #2 make Java easy for "ordinary programmers" doing ordinary businessy programming in a way that ML isn't and probably never will be.
(For the avoidance of doubt, I am not arguing that anyone who is comfortable in ML should use Java instead.)
Yes, ML is pretty good at those underlying principles; yes, you can use it to write code that's compact, safe, and fast; but it's not going to replace Java because #1 and #2 make Java easy for "ordinary programmers" doing ordinary businessy programming in a way that ML isn't and probably never will be.
(For the avoidance of doubt, I am not arguing that anyone who is comfortable in ML should use Java instead.)
I like the ML languages a lot, OCaml could be a java replacement.
There is the industry acceptance part that java has and then the runtime has been pretty well vetted and improved. I'd bet money that ML runtimes turn up with "issues" as larger more demanding applications are built.
And what exactly is going on with SML these days?
There is the industry acceptance part that java has and then the runtime has been pretty well vetted and improved. I'd bet money that ML runtimes turn up with "issues" as larger more demanding applications are built.
And what exactly is going on with SML these days?
OCaml has a long way to go before it can replace java.
http://caml.inria.fr/pub/docs/manual-ocaml/manual038.html
"The threads library is implemented by time-sharing on a single processor. It will not take advantage of multi-processor machines. Using this library will therefore never make programs run faster. However, many programs are easier to write when structured as several communicating processes."
Ocaml is a nice replacement for ANSI C, not for Java.
http://caml.inria.fr/pub/docs/manual-ocaml/manual038.html
"The threads library is implemented by time-sharing on a single processor. It will not take advantage of multi-processor machines. Using this library will therefore never make programs run faster. However, many programs are easier to write when structured as several communicating processes."
Ocaml is a nice replacement for ANSI C, not for Java.
> Ocaml is a nice replacement for ANSI C, not for Java.
That's pretty much how I use it. Ocaml is a great systems language.
That's pretty much how I use it. Ocaml is a great systems language.
Doesn't sound like a long way to me. Or is it just one of many problems?
Threading isn't optional and it isn't an easy project. It will take a long while for Ocaml to catch up, if it ever does.
The other big problem is the underlying OS. Java lives on the JVM, Ocaml lives on Unix. Unix isn't a substitute for the JVM and vice versa.
However, F# might be an ML based competitor to java. I don't know enough about the MS stack to say.
The other big problem is the underlying OS. Java lives on the JVM, Ocaml lives on Unix. Unix isn't a substitute for the JVM and vice versa.
However, F# might be an ML based competitor to java. I don't know enough about the MS stack to say.
I'm surprised about threading being hard. I thought it was just a matter of imitating a state-of-the-art GC. And it's not like it has to play nicely with JIT compilation. Now I agree Ocaml has little chance to catch up, given their apparent interest in the matter.
You're strongly suggesting that a Java replacement has to compile on some standardize byte-code… Might be a prerequisite for proprietary software, but otherwise looks unnecessary. Besides, what do you mean by "lives on UNIX"? Ocaml runs on Windows too…
As far as I know, F# is currently unsuitable: that would be escaping the claws of Oracle to fall in the jaws of Microsoft. Now if Microsoft fully frees .NET, or at least abandons all patent claims regarding it, F# might do.
You're strongly suggesting that a Java replacement has to compile on some standardize byte-code… Might be a prerequisite for proprietary software, but otherwise looks unnecessary. Besides, what do you mean by "lives on UNIX"? Ocaml runs on Windows too…
As far as I know, F# is currently unsuitable: that would be escaping the claws of Oracle to fall in the jaws of Microsoft. Now if Microsoft fully frees .NET, or at least abandons all patent claims regarding it, F# might do.
Threading is hard for even Haskell, which is a pure functional language (unlike ML). GHC has a bunch of fantastic people trying to do a good job, and they haven't finished yet, though arguably they are as good as Java in many ways.
What I mean by "lives on UNIX/lives on JVM" is a fuzzy statement about the Right Way of Doing Things. The Java way is to build a large system, integrated with the rest of the world via one or more public interfaces, potentially accessed via RMI. You'll talk to the database via JDBC. There are highly configurable enterprise tools for almost everything. This is an ecosystem you need to replace if you want to replace java.
The Ocaml way is to write a program that takes command line input and processes a stream of text (which can come from a file or stdin). To write a daemon, you double fork. Most of your interaction with the outside world is simply via a posix interface.
That's not to say you can't write command line unix utils in Java, or gigantic enterprise daemons in Ocaml. But you'll be going against the grain.
What I mean by "lives on UNIX/lives on JVM" is a fuzzy statement about the Right Way of Doing Things. The Java way is to build a large system, integrated with the rest of the world via one or more public interfaces, potentially accessed via RMI. You'll talk to the database via JDBC. There are highly configurable enterprise tools for almost everything. This is an ecosystem you need to replace if you want to replace java.
The Ocaml way is to write a program that takes command line input and processes a stream of text (which can come from a file or stdin). To write a daemon, you double fork. Most of your interaction with the outside world is simply via a posix interface.
That's not to say you can't write command line unix utils in Java, or gigantic enterprise daemons in Ocaml. But you'll be going against the grain.
I think the answer is, at least in large part, right there in your post. There is pretty broad knowledge in the industry of how to build cross-platform C++ applications, practices that weren't mature when Java took off, and this includes targeting IOS. Python and Ruby are great for automation and web development. Is there a need for One Language to Rule Them All? The JVM is the best part of Java IMO and I'm not really clear on where that stands in this current battle, but I know there are JVM implementations out there other than HotSpot.
You can't really compare Java with C++ directly. All they have in common is the syntax style. Java was designed to be C++ programmer friendly, but it shares a lot more with Smalltalk than with C++.
Oracle has pretty much said, Java is for paying customers.
Actually, they said Java on phones is for paying customers and Java on servers will always be free. http://www.theregister.co.uk/2010/11/06/oracle_dueling_jvms/
Actually, they said Java on phones is for paying customers and Java on servers will always be free. http://www.theregister.co.uk/2010/11/06/oracle_dueling_jvms/
> Java on servers will always be free
Great, so I'm free to take a server implementation and port it to mobile phones, right?
Free as in what?
Great, so I'm free to take a server implementation and port it to mobile phones, right?
Free as in what?
As long as you base it on OpnenJDK and don't claim it's Java (you would need the TCK for that) you would be perfectly fine. Just remember not to step on additional patents Oracle may have for the mobile space.
So you can't cliam it does what it has to to be useful and you run the risk of unknown lawsuits on hidden grounds from a large and litigious company who you're trying to outmaneuver to avoid giving them money.
You want to try and build a business doing that?
You want to try and build a business doing that?
> So you can't cliam it does what it has to to be useful
You can always claim it's based on OpenJDK.
> and you run the risk of unknown lawsuits on hidden grounds from a large and litigious company who you're trying to outmaneuver to avoid giving them money
I won't be the one to indulge such a paranoid delusion. Oracle won't sue you for using OpenJDK because they know it would be a lost cause.
You can always claim it's based on OpenJDK.
> and you run the risk of unknown lawsuits on hidden grounds from a large and litigious company who you're trying to outmaneuver to avoid giving them money
I won't be the one to indulge such a paranoid delusion. Oracle won't sue you for using OpenJDK because they know it would be a lost cause.
> Oracle won't sue you for using OpenJDK because they know it would be a lost cause.
Even if it's based on OpenJDK, you still wouldn't get any patent protection. I wouldn't put my trust in Oracle to not sue me over anything...
Even if it's based on OpenJDK, you still wouldn't get any patent protection. I wouldn't put my trust in Oracle to not sue me over anything...
You would. GPLv2 provides an implicit patent grant. Oracle wouldn't be able to touch you.
See http://news.ycombinator.com/item?id=1978507
See http://news.ycombinator.com/item?id=1978507
The weakness of the GPL's patent protection was one of the reasons for the move to v3. I think that you're vastly overestimating the 'implicit' protection that the GPL provides, which to my knowledge has never been tested in court. Even the FSF states this in their FAQ on v3:
In many countries, distributing software under GPLv2 provides recipients with an implicit patent license to exercise their rights under the GPL.
http://www.gnu.org/licenses/gpl-faq.html#v2OrLaterPatentLice...
Many countries, but not all... and it's not clear in the case of v2.
In many countries, distributing software under GPLv2 provides recipients with an implicit patent license to exercise their rights under the GPL.
http://www.gnu.org/licenses/gpl-faq.html#v2OrLaterPatentLice...
Many countries, but not all... and it's not clear in the case of v2.
> The weakness of the GPL's patent protection was one of the reasons for the move to v3
I agree that v3 is more clear about patents than v2, but it's unfair to call a protection that was never used (possibly because it has been a successful deterrent) "weak". It can only be weak if it doesn't protect. So far, it has been effective.
I think the wording in v2 is clear enough. One cannot impose any additional restriction and cannot force fees on users and re-distributors. That protects not only against patents but from anything that looks like one.
I agree that v3 is more clear about patents than v2, but it's unfair to call a protection that was never used (possibly because it has been a successful deterrent) "weak". It can only be weak if it doesn't protect. So far, it has been effective.
I think the wording in v2 is clear enough. One cannot impose any additional restriction and cannot force fees on users and re-distributors. That protects not only against patents but from anything that looks like one.
Basically the new policy is that Oracle develops the JVM and you use it. You don't develop or port the JVM. Because this is totally acceptable to 99% of Java (app) developers, Java will live on. It's too big to fail.
I think you miss the point, it's not acceptable to the mobile Market, Java's mobile offerings are a joke at best and sinister at worst. It took Android to create a competitive platform in the mobile space and Oracle is putting up every effort to squash any runtime work for the mobile space. It is relevant to Java because mobile is the future, tablets and mobile devices will become the dominate computing platform in the next few years and without inovation in that space, Java will be relegated to a language of the past. It is pretty clear that Oracle is dead set on killing Java mobile and I don't think it is because they see a future in Java ME or think they are working on a superior offering. Rather, I am more inclined to believe that they plan to help position the market for Apple to own the mobile platform. Apple being a vertical vendor like Oracle is very complementary to Oracle's world vision and vice versa. Allowing Apache to certify an alternative JVM would allow work to be done to optimize it for mobile. That is the real story behind all of these wrangling.
Java was a safe bet for enterprise software companies - it had wide vendor support: Sun, IBM, WebLogic, Oracle, Apple.
It also had a strong community: Apache, JBoss, etc.
However WebLogic and Sun are now part of Oracle. Apple has backed off on involvement. This leaves Oracle and IBM. IBM are masters of maintaining technology, so we know Java will be maintained. But the ecosystem is being eroded.
If the community is being eroded too, Java advocates everywhere will look somewhere else. Just look at the thread here!
COBOL was too big to fail too. This will not be acceptable to many forward looking enterprise software companies. Expect to see an increasing number of "app servers" appear for Python et al.
It also had a strong community: Apache, JBoss, etc.
However WebLogic and Sun are now part of Oracle. Apple has backed off on involvement. This leaves Oracle and IBM. IBM are masters of maintaining technology, so we know Java will be maintained. But the ecosystem is being eroded.
If the community is being eroded too, Java advocates everywhere will look somewhere else. Just look at the thread here!
COBOL was too big to fail too. This will not be acceptable to many forward looking enterprise software companies. Expect to see an increasing number of "app servers" appear for Python et al.
Java advocates everywhere will look somewhere else. Just look at the thread here!
Right, the writing is already on the wall, because guys like us have already made our mind up that it is on the wall. They have lost the mind-share. Almost every reason for Java's ascension, has been eroded away, the future of Java is exactly what everyone was running from when they found Java. That's why I asked, Oracle's refusal to work with Apache marks the beginning of the end in my mind. It pretty much states openly their plan. The plan that all the "fear mongers" where warning us about. I asked people thought on the Java replacement, because I really would love to know what people see as the successor. For me at least now with the Apache thing decided, it is not a matter of if, it is a matter of "to what".
Right, the writing is already on the wall, because guys like us have already made our mind up that it is on the wall. They have lost the mind-share. Almost every reason for Java's ascension, has been eroded away, the future of Java is exactly what everyone was running from when they found Java. That's why I asked, Oracle's refusal to work with Apache marks the beginning of the end in my mind. It pretty much states openly their plan. The plan that all the "fear mongers" where warning us about. I asked people thought on the Java replacement, because I really would love to know what people see as the successor. For me at least now with the Apache thing decided, it is not a matter of if, it is a matter of "to what".
I still hold out some hope for the Java language, but I share many of your feelings. My main issue in searching for another language is that I don't see many imperative languages with the same kind of methodical approach to object-oriented design and comparable language support for concurrency. The C++ build environment feels like going back to the stone age after using a compiler like javac, and while D seems interesting it still appears to be a rather severe step backwards. Many of Python's design decisions (significant whitespace, idiomatic exceptions-as-flow-control, duck-typing) really rub me the wrong way. I've been tinkering with Lua and FORTH to keep myself sharp, but I can't imagine treating either as a replacement bread-and-butter language like Java.
significant whitespace
Many years ago, this delayed me looking seriously into Python. But when its powerful data structures finally convinced me to start using it, I quickly became accustomed to significant whitespace: I always indented my code correctly anyway, whatever language I'd use. So it was just a case of dropping the { and }. After a few hours I was accustomed to it.
The funny thing is, I still program a lot in C++ and PHP (and Java sometimes). When I write these languages, I fall back on using { and } like I did before, without even noticing it.
Getting proficient in a new language doesn't make you forget your old languages.
Many years ago, this delayed me looking seriously into Python. But when its powerful data structures finally convinced me to start using it, I quickly became accustomed to significant whitespace: I always indented my code correctly anyway, whatever language I'd use. So it was just a case of dropping the { and }. After a few hours I was accustomed to it.
The funny thing is, I still program a lot in C++ and PHP (and Java sometimes). When I write these languages, I fall back on using { and } like I did before, without even noticing it.
Getting proficient in a new language doesn't make you forget your old languages.
I appreciate where you're coming from, but of the three gripes I mentioned whitespace is the least of my concerns. The syntax of Python bothers me much less than the design philosophy.
Any specifics? I may be using Python for so long that I got used to its warts. Some outside perspective could be useful.
I can't answer for the parent poster, but one thing specifically irked me about Python and that was the variable scoping rules and the lack of forced declaration.
The result was that any misspelling of variables could result in extremely difficult to find bugs. This was a final straw that pushed me over the "I don't really care for the syntax of this language much" cliff.
Not a showstopper, but combined with a number of other small complaints, Python "rubbed me the wrong way" too. Yeah, significant whitespace alone isn't a problem. Lack of variable definition by itself isn't a big deal. Explicit "Self" as a parameter is kind of annoying but makes sense. The lame anonymous functions that don't have the full power of the language are ugly. Taken together those are enough to turn me off to the language.
BUT, Python has a few killer features like great libraries, flexible built in data structures, and an excellent foreign function interface. If I needed a scripting language for a native-code app it would be one of the top choices.
By the way, my experience with Python is a few years old, I don't know if anything's changed with the new version.
Edit to add: Other dynamic languages have various solutions to the variable declaration problem, usually involving a parser or compiler warning when you use an unbound variable. Python's syntax would have to change to make that possible, I think.
The result was that any misspelling of variables could result in extremely difficult to find bugs. This was a final straw that pushed me over the "I don't really care for the syntax of this language much" cliff.
Not a showstopper, but combined with a number of other small complaints, Python "rubbed me the wrong way" too. Yeah, significant whitespace alone isn't a problem. Lack of variable definition by itself isn't a big deal. Explicit "Self" as a parameter is kind of annoying but makes sense. The lame anonymous functions that don't have the full power of the language are ugly. Taken together those are enough to turn me off to the language.
BUT, Python has a few killer features like great libraries, flexible built in data structures, and an excellent foreign function interface. If I needed a scripting language for a native-code app it would be one of the top choices.
By the way, my experience with Python is a few years old, I don't know if anything's changed with the new version.
Edit to add: Other dynamic languages have various solutions to the variable declaration problem, usually involving a parser or compiler warning when you use an unbound variable. Python's syntax would have to change to make that possible, I think.
The lame anonymous functions that don't have the full power of the language are ugly.
Tis true, python lambdas are lame, but in practice, their use has been mostly superceded by list (and now set and dictionary) comprehensions.
Edit to add: Other dynamic languages have various solutions to the variable declaration problem, usually involving a parser or compiler warning when you use an unbound variable. Python's syntax would have to change to make that possible, I think.
I don't understand. If you mistype a name, you'll get an error when you run the code.
Tis true, python lambdas are lame, but in practice, their use has been mostly superceded by list (and now set and dictionary) comprehensions.
Edit to add: Other dynamic languages have various solutions to the variable declaration problem, usually involving a parser or compiler warning when you use an unbound variable. Python's syntax would have to change to make that possible, I think.
I don't understand. If you mistype a name, you'll get an error when you run the code.
If you mistype a name, you'll get an error when you run the code.
Depends on the context of the typo. I've had errors along the lines of
Depends on the context of the typo. I've had errors along the lines of
bar=False
...
bat=True
...
if bar:
print "Hi"
> any misspelling of variables could result in extremely difficult to find bugs
Weird. Unless all you do is to attribute them values, Python will complain when you try to use a name that's not in the current namespace.
> The lame anonymous functions
I too complained a lot about them. In the end, all I had to do was to declare the function in the closest scope and pass it to whatever would use the anon function. No big deal.
> warning when you use an unbound variable
Python throws an error when you try to use an unbound name. Python is not BASIC.
Weird. Unless all you do is to attribute them values, Python will complain when you try to use a name that's not in the current namespace.
> The lame anonymous functions
I too complained a lot about them. In the end, all I had to do was to declare the function in the closest scope and pass it to whatever would use the anon function. No big deal.
> warning when you use an unbound variable
Python throws an error when you try to use an unbound name. Python is not BASIC.
As much as I dislike .NET in general (there are some excellent parts) and doing large enterprisey development, I think C# is an excellent language that is only getting better. C# started out as a clone of Java, but it seems to be what Java could have been if it had evolved more rapidly.
If you're concerned about concurrency support, there are new features in .NET 4.0 that I find pretty impressive and nice to use.
That said, I don't know if the story for developing C# applications on Mono is as solid as Visual Studio.
If you're concerned about concurrency support, there are new features in .NET 4.0 that I find pretty impressive and nice to use.
That said, I don't know if the story for developing C# applications on Mono is as solid as Visual Studio.
Interesting.. In what way does D seem like a severe step backwards to you? Is that assumption based on the library support or the language itself?
Do you think it's implausible that Apache could fork Java and Oracle could be eventually left with nothing but a trademark and some loyal corporate customers? With so many prominent Java folks leaving Oracle, I'm not sure what kind of leadership or moral authority they could muster to convince people that they're the most more credible center for the Java community. The community would suffer from a fork, no question, and it would be severely weakened, but I think Java users would prefer to go through such a tribulation rather than write off Java completely.
Personally, I think Apache should fork Java and kick it off with a renaming competition, just to get us past the most traumatic part.
Personally, I think Apache should fork Java and kick it off with a renaming competition, just to get us past the most traumatic part.
I thought the main problem with forking without getting the Java(TM) seal of approval is you may be liable for patent infringement.
Yes, well you couldn't get the Java(TM) seal of approval but there is nothing saying you couldn't make your own "seal of approval". Fork Java, create your own Test Compatibility Kit, and start approving implementations. Done.
That wouldn't help against Oracles patents, which they are seemingly happy to use.
May, might, could, Apache and Google have lawyers who can provide a much better answer to that question if they're asked (and paid) to do it. Even if the odds are less than even, if people really believe that Java is dead under Oracle, they will risk a lot for a chance to salvage the massive investment that thousands of companies and thousands of open-source projects have made in Java.
Do you think it's implausible that Apache could fork Java
I thought Apache already did that, that's how the Apache Harmony project started. This was all done before Java was open source and one needed a 'free as in speech' java.
I thought Apache already did that, that's how the Apache Harmony project started. This was all done before Java was open source and one needed a 'free as in speech' java.
> JVM languages are too close to Oracles reach for comfort
Not at all. All of them run on the OpenJDK and the GPL makes it Ellison-proof. He can scream an threaten all he wants.
OpenJDK is not as cool as all the Sun-invented niceties in their own VM implementations, but it's good.
Not at all. All of them run on the OpenJDK and the GPL makes it Ellison-proof. He can scream an threaten all he wants.
OpenJDK is not as cool as all the Sun-invented niceties in their own VM implementations, but it's good.
I don't believe that the GPL gives you patent protection. (GPL 3 does, but this is the GPL 2 I think)
GPLv2 gives an implicit grant. You cannot distribute your code under GPLv2 unless you can ensure the user has full right to use and redistribute your code.
Section 6 says "You may not impose any further restrictions on the recipients' exercise of the rights granted herein."
Section 7 says "if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program."
The scope may be different under different laws (that's one of the reasons GPLv3 makes it explicit) but it's pretty much reasonable to assume Oracle would rather not test it on court.
Section 6 says "You may not impose any further restrictions on the recipients' exercise of the rights granted herein."
Section 7 says "if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program."
The scope may be different under different laws (that's one of the reasons GPLv3 makes it explicit) but it's pretty much reasonable to assume Oracle would rather not test it on court.
When Java was released in '95 it replaces Smalltalk in the Enterprises (mainly banks). And during this decade Smalltalk was down to little or no usage till useful stuffs (Seaside and Pharo comes to mind) bring it back to life.
Can Smalltalk be the new (old) stuff?
Can Smalltalk be the new (old) stuff?
In order to truly replace Java, any language really, really needs to think about the ecosystem around the language. Smalltalk vendors really do not have a good deployment strategy, certainly nothing as comprehensive as Java.
The other problem is that Smalltalk is pretty alien to a Java programmer (image vs. text, block based control flow vs. traditional control flow). Garnett and Forester's recommendations might be key.
Although, I still would argue the premise and say most of these institutions know Oracle and understand dealing with them. I don't see people giving up their Oracle databases and having bundled, recommended Java might make Java more of a lock.
The other problem is that Smalltalk is pretty alien to a Java programmer (image vs. text, block based control flow vs. traditional control flow). Garnett and Forester's recommendations might be key.
Although, I still would argue the premise and say most of these institutions know Oracle and understand dealing with them. I don't see people giving up their Oracle databases and having bundled, recommended Java might make Java more of a lock.
Language shouldn't matter, it's the tools around it. Now instead of having one massive amount of tools for a single language, the way of the future (that's already here, actually) is fragmentation and cooperation. Ever heard of LAMP? It's four very different tools and multiple languages that make up only a part of a larger software stack that is only for a particular purpose. This works surprisingly well, and it's easy to swap out any piece you want with another. And this wasn't by design of some massive company like Sun or Oracle, but merely cooperation and good old software interfaces.
please cite the link for this statement "Java is for paying customers." 'Cause without this link , it seems you are merely spreading FUD.
I'm not sure what you're looking for. You want a link to an attitude or pattern of behavior?
I would settle for a link -- from an analyst or a press release to back up that claim. Otherwise , this thread (not the parent article)is just FUD.
You not too familiar with Ellison's frequent ramblings on this subject are you? Take a look at the link below I think it will open your eyes to how Ellison views Open Source, he sees very little value in it and will not buy Open Source companies because he feels that he cannot monetize them. To the potential that he would want to. It is natural to draw the conclusion that he sees Suns free offerings in the same light as he has never changes position on the subject. It is no big secret that the only kind of customer Oracle has is the paying kind.
http://us.ft.com/ftgateway/superpage.ft?news_id=fto041820061...
As well as this one where they pretty much say yep we are going to monetize the JVM.
http://www.theregister.co.uk/2010/11/06/oracle_dueling_jvms/
We see in China and India, all that stuff is freely available and Red Hat is just cut completely out of the market. I'm not gong to spend $5bn, or $6bn, for something that can just be so completely wiped off the map. They take all the Red Hat code, have their own equivalent of the Red Hat network, and Red Hat gets zero.
So its all very interesting. You can build a sustainable business [in open source], you just can't charge a lot for it. There's brand value – there's real brand – there's people, and that's it.
http://us.ft.com/ftgateway/superpage.ft?news_id=fto041820061...
As well as this one where they pretty much say yep we are going to monetize the JVM.
http://www.theregister.co.uk/2010/11/06/oracle_dueling_jvms/
We see in China and India, all that stuff is freely available and Red Hat is just cut completely out of the market. I'm not gong to spend $5bn, or $6bn, for something that can just be so completely wiped off the map. They take all the Red Hat code, have their own equivalent of the Red Hat network, and Red Hat gets zero.
So its all very interesting. You can build a sustainable business [in open source], you just can't charge a lot for it. There's brand value – there's real brand – there's people, and that's it.
I don't think you understand what "that claim" is. Nobody's claiming that Oracle literally said the words you put in quotation marks. The actual claim you are disputing, as far as I can tell, is that Oracle's recent actions have shown an intent to take Java from a free programming language to a money-making venture and oppose implementations that don't put money in Oracle's pockets. See, for example, the suit against Google and the sidelining of Harmony. The article itself notes that even the groups supporting Oracle's technology roadmap are troubled by its business decisions around Java.
None of this is the kind of thing most people would look for in a press release.
None of this is the kind of thing most people would look for in a press release.
Shouldn't the opinion of developers in the trenches have more weight than some ivory tower analyst or newspeak press release?
I fail to comprehend your objection. The licensing terms are what is at dispute here and not the technical merits of the language or the JVM platform. These were the same terms ( more or less ) when you downloaded the first JDK. Apache and Google are disputing the licensing terms . Oracle has nowhere said Java is only for paying customers. Just chillax !!!
"Oracle has nowhere said Java is only for paying customers"
They killed OpenSSO, they killed Open Office, the killed Open Solaris, They where contractually bound to not kill MySQL so they just raised the price through the roof to send the message. Pretty much they killed anything that you did not have to pay for. The worst part is they did not just withdraw paid positions from working on it. They alienated the volunteer members of the community until they resigned in protest.
Sun agreed to license the TCK to Apache under non-discriminatory terms an Agreement that Oracle is not, has not and will not living up to, because they don't want JDKs to exist that did not pay Oracle or more importantly they want them to licence it under the restrictive provising that they require e.g no use on servers and no use on Mobile. How many more items do they have to destroy until people start seeing the serial and systematic behavior that is going on.
do you not find it funny that Apple gave the JVM back to Oracle and Oracle is doing everything in it's power to keep non-sanctioned VM's off of Mobile devices. That is what the Apache dispute is really about, Oracle does not want a non-oracle JVM in the mobile world and I can bet you dime to dollar that it has to do with a back room deal between Oracle and Apple. Why do they want to keep the non-sanctioned JVM's off of Mobile devices, well because a closed ecosystem is more lucrative for Apple and Oracle than one in which Apache and Google are giving stuff away for free.
There is a fundamental difference in world views between Apple / Oracle and Google / Apache. Apple and Oracle are vertical stack providers they want to provide the whole stack soup to nuts and don't want anyone playing in their ecosystem, it just so happens that Apple wants the consumer market and Oracle wants the Enterprise market so they make good bed fellows. They are about the only two tech companies left that are not at war with each other.
Google and Apache represent a threat to their world vision and they have declared war to stop them. Oracle is all about every piece of their vertical being a piece that is monetized you can rest assured that Java is no exception.
Like it or not Java and the JVM are pawns in a big game of who is going to own the mobile market. It is the future market and winner takes all, if Oracle backs Apple in wining the market, then Apple can ensure that Oracle is position to be the Enterprise infrastructure for the new Mobile market. Like it or not, Java is a sacrificial pawn in a bigger game now.
The developer in me does not care, quite honestly the return to verticals means the return to easy money for writing software for verticals but the consumer in me shudders at the though of the verticals winning. You think Apples platform is restrictive, now wait until they own 90% of the market. They will make the early 90's Microsoft look like a benevolent democracy and well Oracle will just become a technical tax to anyone wanting to do business.
They killed OpenSSO, they killed Open Office, the killed Open Solaris, They where contractually bound to not kill MySQL so they just raised the price through the roof to send the message. Pretty much they killed anything that you did not have to pay for. The worst part is they did not just withdraw paid positions from working on it. They alienated the volunteer members of the community until they resigned in protest.
Sun agreed to license the TCK to Apache under non-discriminatory terms an Agreement that Oracle is not, has not and will not living up to, because they don't want JDKs to exist that did not pay Oracle or more importantly they want them to licence it under the restrictive provising that they require e.g no use on servers and no use on Mobile. How many more items do they have to destroy until people start seeing the serial and systematic behavior that is going on.
do you not find it funny that Apple gave the JVM back to Oracle and Oracle is doing everything in it's power to keep non-sanctioned VM's off of Mobile devices. That is what the Apache dispute is really about, Oracle does not want a non-oracle JVM in the mobile world and I can bet you dime to dollar that it has to do with a back room deal between Oracle and Apple. Why do they want to keep the non-sanctioned JVM's off of Mobile devices, well because a closed ecosystem is more lucrative for Apple and Oracle than one in which Apache and Google are giving stuff away for free.
There is a fundamental difference in world views between Apple / Oracle and Google / Apache. Apple and Oracle are vertical stack providers they want to provide the whole stack soup to nuts and don't want anyone playing in their ecosystem, it just so happens that Apple wants the consumer market and Oracle wants the Enterprise market so they make good bed fellows. They are about the only two tech companies left that are not at war with each other.
Google and Apache represent a threat to their world vision and they have declared war to stop them. Oracle is all about every piece of their vertical being a piece that is monetized you can rest assured that Java is no exception.
Like it or not Java and the JVM are pawns in a big game of who is going to own the mobile market. It is the future market and winner takes all, if Oracle backs Apple in wining the market, then Apple can ensure that Oracle is position to be the Enterprise infrastructure for the new Mobile market. Like it or not, Java is a sacrificial pawn in a bigger game now.
The developer in me does not care, quite honestly the return to verticals means the return to easy money for writing software for verticals but the consumer in me shudders at the though of the verticals winning. You think Apples platform is restrictive, now wait until they own 90% of the market. They will make the early 90's Microsoft look like a benevolent democracy and well Oracle will just become a technical tax to anyone wanting to do business.
I am not defending Oracle. My point is that regardless of the jockeying in the mobile world, Java language and the JDK which you and I both use has no threat to its future. There are no technical issues that jeopardize the Java language's future or the JVM's future. Oracle understand the significance of the Java developer community. Sure it would have been nice to have Harmony but I am able to live with openJDK. Remember, IBM and Apple are both supporting OpenJDK -- Oracle is not the sole custodian of Java. There is no impact to JDK and JRE on servers ( which is where I suspect most of us Java programmers make our bread and butter). Sure the Mobile platform is being contested -- but so what ? Businesses always jockey for position .
Yes there is some validity to what you are saying, for a while we can go on as if nothing is wrong. The problem is that Oracle has a track record of trying to monetize anything that has significant leverage. Look what they just did with mySQL, pretty much doubled the prices. I fear that more and more items will become additional paid features as time goes on.
> Oracle understand the significance of the Java developer community.
Really? How, where, when?
Really? How, where, when?
The value of the Java community, for Oracle, is measured by those that are paid to develop Java for licensed (or sold) software products. If you don't to that then you don't get counted.
"IBM and Apple are both supporting OpenJDK -- Oracle is not the sole custodian of Java" Whilst technically correct, they appear to be holding the TCK and patents as viable weapons in the battle for control.
"IBM and Apple are both supporting OpenJDK -- Oracle is not the sole custodian of Java" Whilst technically correct, they appear to be holding the TCK and patents as viable weapons in the battle for control.
> Sun agreed to license the TCK to Apache under non-discriminatory terms an Agreement that Oracle is not, has not and will not living up to
If Oracle is in breach of an agreement, can Apache take them to court of force them to comply?
Alternately, are there any legal obstacles preventing Apache from writing their own TCK and saying in future they'll develop against that?
If Oracle is in breach of an agreement, can Apache take them to court of force them to comply?
Alternately, are there any legal obstacles preventing Apache from writing their own TCK and saying in future they'll develop against that?
If Oracle is in breach of an agreement, can Apache take them to court of force them to comply?
Apache doesn't have enough money to do that, and if they did their members would probably consider such a lawsuit a waste of said money.
Alternately, are there any legal obstacles preventing Apache from writing their own TCK and saying in future they'll develop against that?
Patents that are owned by Oracle.
Apache doesn't have enough money to do that, and if they did their members would probably consider such a lawsuit a waste of said money.
Alternately, are there any legal obstacles preventing Apache from writing their own TCK and saying in future they'll develop against that?
Patents that are owned by Oracle.
> Apache doesn't have enough money to do that
No, but if they can convince telcos and phone manufacturers they can win, I am sure they could direct some of the money provisioned for J2ME licencing and Android-related patent-licensing into that.
No, but if they can convince telcos and phone manufacturers they can win, I am sure they could direct some of the money provisioned for J2ME licencing and Android-related patent-licensing into that.
Apache can write their own test suite, but their products can't be legally branded as "Java™" without passing the TCK. Of course, a cleanroom implementation of Java can pass the TCK yet still contain bugs that make it unsuitable for production use. Even if the licensing issues went away I can't see how an Apache Java would ever see enterprise adoption.
More important than not being able to call it Java, I believe thar if they don't pass the TCK, they do not get a license to the patents.
> They killed OpenSSO, they killed Open Office, the killed Open Solaris, They where contractually bound to not kill MySQL
And you know the beauty of it? Then can't kill neither Open Office nor MySQL. When the time comes, I just have to move to a fork. LibreOffice is on RC-stage now and I am curious about Drizzle and the other forks of MySQL.
> because they don't want JDKs to exist that did not pay Oracle
Probably. What they would really hate would be not to get some money out of every feature phone out there. Their thing is with mobile and J2ME licensing means a lot of money.
> They will make the early 90's Microsoft look like a benevolent democracy
Don't get me started on that...
And you know the beauty of it? Then can't kill neither Open Office nor MySQL. When the time comes, I just have to move to a fork. LibreOffice is on RC-stage now and I am curious about Drizzle and the other forks of MySQL.
> because they don't want JDKs to exist that did not pay Oracle
Probably. What they would really hate would be not to get some money out of every feature phone out there. Their thing is with mobile and J2ME licensing means a lot of money.
> They will make the early 90's Microsoft look like a benevolent democracy
Don't get me started on that...
There is GNUstep for Apple-free Objective-C (http://gnustep.org/), and Vala is another interesting modern language (http://live.gnome.org/Vala)
[deleted]
Oracle has been quite clear that Java will continue as it always has for normal, non-paying customers. Only the JRockit stuff which they were already charging for will be pay-for in the future.
But whatever, FUD away.
But whatever, FUD away.
Oracle has been quite clear that Java will continue as it always has for normal, non-paying customers
Not on mobile that have not, in fact they have stated quite the opposite. With mobile projected to surpass desktops in 18 months that is cause for concern. Make no mistake about it, the wranglings with Apache and the patent suit with Google are intricately related. This is all about ownership of mobile.
Not on mobile that have not, in fact they have stated quite the opposite. With mobile projected to surpass desktops in 18 months that is cause for concern. Make no mistake about it, the wranglings with Apache and the patent suit with Google are intricately related. This is all about ownership of mobile.
I can't help but wonder why Google is apparently willing to spend $6B on Groupon, but wasn't willing to spend roughly the same to secure a significant portion of the intellectual property assets that Google is heavily dependent upon.
Is Groupon really as or more valuable than Sun to Google?
Is Groupon really as or more valuable than Sun to Google?
Good observation. Yes, it makes sense, because Google is a media company, and not a technology company like many people think.
It seems clear that one large part of the equation for Oracle was being able to sue Google to recoup the cost. This obviously doesn't work well for Google. In addition, Google doesn't have a stellar history of integrating acquisitions (it has had a tough time with youtube), and I can't imagine they thought it prudent to try to integrate Sun.
Still, it is a nice dream, isn't it?
Still, it is a nice dream, isn't it?
So what does the HN community think of Vala (http://live.gnome.org/Vala)? C# like syntax. Compiles down to C. Reference counting for memory management. Appears to work with clang as well.
More example syntax here: http://live.gnome.org/Vala/Tutorial
More example syntax here: http://live.gnome.org/Vala/Tutorial
We use it on the server side with http://midgard2.org/
Check out https://github.com/midgardproject/midgard-core/tree/master/s...
Check out https://github.com/midgardproject/midgard-core/tree/master/s...
Looks interesting for low-level stuff. I assume memory management will become more sophisticated with time.
You can't do sophisticated GC in C. The memory model of the JVM is important - it knows what is a pointer and what is data, which is important for efficient GC.
If course you can. But you will have to write a memory manager for that and make the compiler keep track of what your pointers point to. I don't know enough about Vala to say it's not desirable given its syntax and what it assumes about the memory management the program does, but it's not impossible.
It may be a whole lot of work.
It may be a whole lot of work.
actually, you can do consevative GC in C just fine without any special support in compiler, see Boehm's GC. Which is actually what was until recently used in Mono and also extensively used by various other runtimes (gnu java, ecl, many scheme implementations...)
True, but it would be uglier than if the compiler hid the CG behind a wall of syntactic sugar.
Well, the only difference you see is that you call GC_malloc() instead of malloc() (and that can be redefined, even link-time), and that on some platforms (at least Cygwin and AIX, maybe also Solaris) you need to call GC_INIT() from main().
Yes, but that should be placed in the C code, not in the Vala sources. Assuming it's a c#/Java-like language, the programmer should be spared from this job.
In case of Vala I think that required modifications are pretty well limited to underlying runtime library (gobject) and do not touch compiler too much. But on the other hand they will be quite invasive across whole Gtk/Gnome platform.
Thanks, but no thanks.
Results are out. http://jcp.org/en/jsr/results?id=5111
Quite a few of those who voted yes added comments about the yes being on technical merit, not licensing.
Quite a few of those who voted yes added comments about the yes being on technical merit, not licensing.
Interesting to see that e.g. Eclipse and Red Hat voted yes.
Since it seems that the concept of compiling code to an intermediate bytecode run in a JIT-VM seems to have proven itself pretty well (and the concept of compiling multiple languages to said VM a la Scala), perhaps it's time for the community to look at building their own from the ground up VM with associated language support?
Perhaps https://www.parrot.org/ ?
Perhaps https://www.parrot.org/ ?
The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. Despite its name, LLVM has little to do with traditional virtual machines, though it does provide helpful libraries that can be used to build them.
If LLVM is not a VM, do you have a particular LLVM-based VM in mind?
If LLVM is not a VM, do you have a particular LLVM-based VM in mind?
Just reframe the question. Rather than assuming that what we need is a standardized VM, instead assume that what we need is a standardized IR (Intermediate Representation). It solves the same problem, makes LLVM-IR a viable alternative, and leaves the world free to make multiple, interoperable implementations rather than one monolithic implementation.
LLVM does include a VM, although that's not the focus.
I'm wondering if it might be better suited in this context to producing byte-code for Parrot?
Why? It seems perfectly capable of producing native code.
Because sometimes compiling to an intermediate VM has advantages over compiling to native code.
http://news.ycombinator.com/item?id=1977956
http://news.ycombinator.com/item?id=1977956
I'd read that comment, which is in this very thread (!), I just don't see why you'd want to do that.
Which part doesn't make sense, running intermediate byte-code in a VM, or using LLVM to target Parrot? If it's the former, I'm not sure I can persuade you in this thread if a decade of enterprise software can't do that, if it's the latter, then I can see that also.
LLVM as noted. But the problem is that if Oracle's lawsuit against Google is successful, then any VM that's remotely similar to Java's is threatened.
Could Harmony just rebrand and go its own way? i.e. people would be "Harmony developers" instead of "Java developers" but it would be the same thing. Or are there patent or licence obstacles to this? A platform run by Google and Apache would have a core of great engineering and the pick of the best libraries.
I appreciate that ASL is in reality an impossible boat to turn because it relies on the voluntary contribution of dozens of key developers, each running private projects with investments in software based on the existing VM tradition.
I appreciate that ASL is in reality an impossible boat to turn because it relies on the voluntary contribution of dozens of key developers, each running private projects with investments in software based on the existing VM tradition.
The features in JDK 7 and 8 are what we the Java developer community have been asking for. Heck, even RedHat held its nose and voted yes for the technical merits. Java is only getting beter and the JVM -- thanks to Clojure , Scala and JRuby -- has a vibrant community that is extending it beyond the limitations of Java.
But please don't let these facts get in the way of Java fear mongering. Good to see the Java haters' FUD factory is back in action. The old " java is too slow" campaign was losing its appeal. Good to see a fresh new FUD.
But please don't let these facts get in the way of Java fear mongering. Good to see the Java haters' FUD factory is back in action. The old " java is too slow" campaign was losing its appeal. Good to see a fresh new FUD.
While the situation is far from perfect, I am at least happy that actual progress is made, as we have a release date for JDK7 and respective JSRs at last.
Regarding the "premium JDK", I dont mind Oracle charging companies like investment banks extra bucks for additional JRockit-features (Monitoring, etc) that the open source community never actually had free access to anyway. There are so many Oracle products that heavily depend on Java, that it does make no sense for them to hurt Java. If they destroy Java, they destroy part of their income, which I just dont see happening. Although the geekish OSS-nature of Sun's stewardship is gone, things could be by far worse for the Java ecosystem.
Speaking from our situation, I dont see us switching to .NET any time soon. Although it is a great platform especially with the recent developments on C#, for us it is just not cost-effective to buy new Windows Server, SQL Server, etc licenses for every new non-trivial project. It is just far easier and cheaper to build a new Debian-machine on our VMWare cloud and apt-get whatever we need.
Regarding the "premium JDK", I dont mind Oracle charging companies like investment banks extra bucks for additional JRockit-features (Monitoring, etc) that the open source community never actually had free access to anyway. There are so many Oracle products that heavily depend on Java, that it does make no sense for them to hurt Java. If they destroy Java, they destroy part of their income, which I just dont see happening. Although the geekish OSS-nature of Sun's stewardship is gone, things could be by far worse for the Java ecosystem.
Speaking from our situation, I dont see us switching to .NET any time soon. Although it is a great platform especially with the recent developments on C#, for us it is just not cost-effective to buy new Windows Server, SQL Server, etc licenses for every new non-trivial project. It is just far easier and cheaper to build a new Debian-machine on our VMWare cloud and apt-get whatever we need.
Can't you "apt-get install mono"?
What does all this mean? How did this even happen? Can someone give me the summary? I haven't really kept up with this from the beginning.
This has been going on for something like eight years so it's not easy to summarize. But you might start here: http://www.jroller.com/scolebourne/entry/sun_apache_ip_in_pi...
The article is a little misleading; the refusal by Oracle is to not let them run the certification tools _for_free_; every other JDK developer has paid for certification. Apache won't pay; so they don't get certified.
Would it be possible to "fork" Java?
Alternatives could probably be Parrot or LLVM?
The power of Java is not the VM, or even the system runtime, but the open source libraries available for it. It is time to create a "new language" whose compiler will accept Java, and whose VM implementation is unencumbered by legitimate patents. Hm. If Dalvik isn't it, then something similar will be created. I, for one, would like to help. Anyone else up for it?
Java is the prototypical Blub. It's saddled with a type system that wasn't even state of the art in 1991, motivating gigantic enterprisey libraries of RequestSpecificProcessorFactoryFactory crud. The VM is the reason we grudgingly tolerate it where I work.
It may be "prototypical Blub," but it has attracted a lot of bright and effective programmers, including several top-ten finishers in the Google AI Challenge and many, many people writing oodles of useful, practical code. I think it's fair to say from history that if you want to get things done in a cool, nicely designed language, it helps if your cool, nicely designed language runs on a platform that is dominated by a popular Blub language.
Proof: If there's no Blub on your platform, you'll exclude the vast majority of people who might write useful code you can use. If there is a Blub on your platform, its popularity will ensure that the vast majority of useful code on your platform will be written in Blub, and first-class language status on your platform will be defined by ability to interoperate with Blub. Therefore, the best case scenario is for your favorite language to be a minor player on a Blub platform.
Proof: If there's no Blub on your platform, you'll exclude the vast majority of people who might write useful code you can use. If there is a Blub on your platform, its popularity will ensure that the vast majority of useful code on your platform will be written in Blub, and first-class language status on your platform will be defined by ability to interoperate with Blub. Therefore, the best case scenario is for your favorite language to be a minor player on a Blub platform.
Why Java interoperability instead of a good C FFI? That's what Perl/Ruby/Python/Lua/... are doing, and it works for them.
C is another Blub, so you aren't contradicting my point, but I would say that the reason C isn't a good replacement for Java is that C has no support for garbage collection. C and Java both have a large amount of valuable, working code that programmers can utilize from other languages, but a language written on top of C has to accept that whenever a C library is used, someone must deal with C memory management, either the programmer who writes the bindings or every programmer who calls the bindings. They may have to deallocate memory and they may have to reason about the lifetime of memory deallocated by library code. Scala programmers can call Java code with no such worries. If they wrap a Java API in a Scala API, it is only for style and convenience. A Scala programmer would not use a C library lightly, certainly not without bindings that ensured memory safety, and writing such bindings would require a lot of care.
The difference in practice is obvious: there is no Scala "FFI" to Java, at least not one that is visible to programmers. You just instantiate Java objects and call their methods. Ruby programmers do not blithely write calls directly to C functions in their Ruby code. They look for bindings, write the bindings themselves if necessary (making sure the bindings handle all the C memory management safely,) and then call the bindings from their Ruby code.
Where increased performance is worth such an investment of time and care (and a little bit of unavoidable risk) it makes sense to build a language on top of C. Java caters to a different set of needs, where convenience and safety trump performance.
P.S. The Java community went through a phase back in the day when many libraries were wrappers around C libraries, for performance reasons or simply because there was no Java implementation available, and it was a big problem because it invalidated some of the guarantees that attracted people to Java in the first place. Almost all (very, very close to all) of the cross-platform discrepancies encountered in server-side Java code were because the same C library behaved differently on different platforms.
The difference in practice is obvious: there is no Scala "FFI" to Java, at least not one that is visible to programmers. You just instantiate Java objects and call their methods. Ruby programmers do not blithely write calls directly to C functions in their Ruby code. They look for bindings, write the bindings themselves if necessary (making sure the bindings handle all the C memory management safely,) and then call the bindings from their Ruby code.
Where increased performance is worth such an investment of time and care (and a little bit of unavoidable risk) it makes sense to build a language on top of C. Java caters to a different set of needs, where convenience and safety trump performance.
P.S. The Java community went through a phase back in the day when many libraries were wrappers around C libraries, for performance reasons or simply because there was no Java implementation available, and it was a big problem because it invalidated some of the guarantees that attracted people to Java in the first place. Almost all (very, very close to all) of the cross-platform discrepancies encountered in server-side Java code were because the same C library behaved differently on different platforms.
Not true. The VM is very important. The consistent & unified memory model is why Java can do synchronising, threading, garbage collection efficiently, cross platform and consistently.
Also, HotSpot is really important. Java is an acceptable systems language at 80-110% the efficiency of C. It's not at 50% or less.
Also, HotSpot is really important. Java is an acceptable systems language at 80-110% the efficiency of C. It's not at 50% or less.
As can many other languages. However, when I use .NET, I find myself wishing for maven and all the libraries immediately available. Without the VM, there would be no point in having the source. However, even with a great VM, other languages fall short of Java, IMHO. YMMV.
There are also areas where the Java VM totally sucks, frankly. How is it that we only have decent IO after more than 10 years? Sun and now Oracle hold the Java community hostage with the VM and runtime. Time to move on.
There are also areas where the Java VM totally sucks, frankly. How is it that we only have decent IO after more than 10 years? Sun and now Oracle hold the Java community hostage with the VM and runtime. Time to move on.