We have a project which (assumed) would be finished in 1-2 years. By then, the JDK7 (and hopefully the Java7 JCP spec) should be ready.
But, I wonder, how probable is the "danger" that Oracle will make a "stupid" decision, which would make the JDK7 a less "attractive" platform then the existing JDK6?
More specific, I'm afraid of scenarios such as:
halting the development of JDK7 before it is "released"
changing the licensing model to be more restrictive than JDK6
...are there other scenarios to be aware of?
What is your opinion on the issue?
NOTE: We would use the NIO2 files API, and perhaps other JDK7-only features which were accepted for "Plan B" (Plan A was rejected, was a proposal to continue to develop JDK7 much longer, instead, Plan B was accepted: develop JDK7 with less features and postpone them for JDK8)
It depends on how many Java 7 specific features you use.
If your code can still compile on JDK 6, I'd say you're quite safe. You can run on JDK 7, since it's backwards compatible, but if there's an issue you can still deploy on 6.
If Oracle does something really stupid you'll have a bigger decision on my hands: Do I rewrite this app in C#, Python, or something else?
I'll be curious to see how well open source JDK will allow you to hedge your bet.
I'd also be curious to see which features of JDK 7 you're already using: closures?
If you're concerned about risks associated with Java 7, you can mitigate them by ensuring your code will run on Java 6. The easiest way to do this is to develop atop Java 6 now, then upgrade to Java 7 once those risks have dissipated.
In addition to the risks you've noted, the set of features planned for Java 7 is in flux.
Related
I hope this is not off-topic for SO (I hesitated between SO and programmers.stackexchange) but as far as I can tell this is a "practical, answerable problem that is unique to the programming profession" so it's complying with the FAQ.
Which version of the JVM do you need in order to run which version of Clojure (Clojure on the JVM, this question is not about ClojureScript)?
The page here: http://clojure.org/getting_started states that:
Clojure requires only Java 1.5 or greater
But is this always going to be the case?
And what about the Clojure ecosystem, like Leiningen?
Basically I'd like to know if I can count on Clojure to be able to develop a desktop app that should run on systems, including OS X systems, that are never going to get Java 6 nor more recent versions of Java (for example on some OS X versions Apple stated that no JVM 6 would ever see the light).
I am not on the Clojure/core team, so I don't have inside information, but here is how I would approach this situation.
Take the latest version of Clojure (1.5 as of this writing) and test it against Java 1.5 for the things you need to do and any Clojure libraries you need to use and stick with that. If Clojure 1.5 is Java 1.5 compatable, it will always be so, since that release is immutable.
I would not make the assumption that all Clojure versions after 1.5 will be Java 1.5 compatible and you definitely can't assume that Clojure libraries will be. For example, I just released a Clojure library that requires Java 1.7 (since it uses a java.util.concurrent class introduced in Java 1.7).
Since Leiningen gives you maven-like dependency resolution if you test all your libraries and your chosen version of Clojure against Java 1.5 and they work, then you can stick with that set of versioned dependencies for as long as you want to keep the app running. Your only risk at that point is that some bug fix releases of a non core library might not be Java 1.5 compatible any longer. This risk is proportional to how many non-core Clojure libraries you need to use.
If you are selective about what libraries you use, then targeting Java 1.5 is certainly feasible.
Clojure is very conservative about it's Java version requirements - hence the dependency on version 1.5 only.
Many libraries depend only on Clojure itself, so will run quite happily on the 1.5 JVM
Some libraries require >1.5, these tend to be more advanced libraries that have requirements for interop with specific Java features (e.g. newer concurrency code).
Note: I personally write all my apps/libraries to target Java 1.6, since I think that is a reasonable minimum and the vast majority of Java-based systems are at 1.6 or above. I'm willing to live with the potential loss of a few users who are stuck on 1.5. Also, even if a future version of Clojure does abandon 1.5, I expect it will continue support for Java 1.6 for a long time.
Notably, in Clojure 1.6 they have bumped the version of Java to 1.6:
The Clojure 1.6 Release Notes
include this ticket:
CLJ-1268: Require Java 1.6 as minimum for Clojure
So, "no" is the answer to the original poster's question of "But is [Clojure requires only Java 1.5 or greater] always going to be the case?"
I've been debating whether or not to bundle a JRE with my application. I've listed some reasons below why I think it would be useful, but I'm also hesitant to do this because it makes the app much larger.
Why I think it would be useful:
Right now the app is run by running a batch file (well, a shortcut to a batch file, it is run via a batch file). It just calls java -jar XXX, which requires Java to be in the path, which is not always the case.
We're a small team and not fully running on Java 7 (there are some strange errors we are trying to debug still). If a user has Java 7, they may have an unpleasant software experience - this is not good for us. Packaging a specific version of the JRE ensure we've fully tested on it.
We support 32 and 64 bit Windows platforms. When the user downloads the software, they choose 32 or 64-bit, but this is asking which version of Java are they using. Most users don't know if 32-bit java is installed on their 64-bit platform, and it can be confusing to download 32-bit even though their OS is 64-bit.
There are some good reasons why not to package it though:
If a security hole is in Java or other significant updates are made to the JRE, we need to distribute a new version of our app with a new Java version. We are generally updating our app every couple of weeks, so I'm not too concerned about this one right now.
The app will now be much larger because it includes a packaged JRE.
Can anyone provide some guidance as to whether or not (based on these requirements) they think it is a good idea to package the JRE? If not, what are some alternatives to just hoping that java is in the path (and more importantly if it's not, it is possible our users may not know how to add it).
Java Web Start. The JRE will be on the path.
For version control, see Java Web Start - Runtime Versioning & particularly Earlier Version.
JWS can partition resources between a 64 bit & 32 bit JRE.
So, 'bad idea to bundle JRE'. Use web-start instead.
I would suggest to NOT bundle the JRE although I often see it as a common practice.
Instead I would either use webstart (can be used offline as well) or some other installer or pacakge manager solution that ensures that Java is installed including the correct version. This will widely depend on the operating system you expect to run on.
Going down the way of including Java begs the question what else you want to include, just to be sure... which will lead you to the whole operating system and everything needed thought to the end.
I would also suggest to closely look into what types of users will install the app and adapt to that and make some sort of estimate on how capable they will be.
I have the following directive in my sources:
#import <scrrun.dll>
Can I rely on this DLL being pre-installed with Windows?
How relying on this limits Windows versions, which can be used?
You are asking us to predict what a very large company like Microsoft is going to do in the, what, next 10 years. Impossible to answer accurately of course.
Nevertheless, the scripting runtime is available in the latest version of Windows, got ported to 64-bits, has no obscure or desperately ancient or deprecated dependencies. It is used in many programs. Microsoft has a very strong commitment to app-compat.
Odds are very good that you are not going to have to worry about it for a long time.
I'm wondering if anyone has any information or speculation as to when or if there will be a native windows version/port of Node.js.
There is an ongoing effort to provide a mingw port of Node.js. Version 0.3.6+ can be build that way.
However that is still experimental and anything but ready for more than quick and dirty development. Even in case this version matures, I suppose that it will always lag behind the *nix versions, mainly due to the fact that the event loop implementations that Node uses were originally written for those systems and APIs.
The windows version may become stable for development at some point in the future, but I hardly doubt it will ever be usable for production.
July 2011 Update:
#nodejs v0.5.1 is the first to ship with an official Windows executable. We're hoping to get some good feedback.
Microsoft has officially gotten involved with joyent in making node.js work natively on windows.
If one or two Windows C++ developers would put in the effort, then they could fill the gaps in the native Windows version and produce a node.js implementation that would be usable for production.
For now, there is a working Cygwin version and I don't know of any testing that shows it to be unsuitable for production. It certainly works fine (version 0.5.0pre) for development.
Have a look at:
http://www.rafaljonca.org/d/nodejs-windows
Which is based on the work of these guys here
http://node-js.prcn.co.cc/
Both good ways of getting node on windows if you dont have cygwin. However after many heartaches I found developing Node stuff on windows easiest by just using virtualbox with the ubuntu image.
Tnx
GT
I am strictly a Windows Dev and I have wanted to mess around with Node.js for quite a while.
It looks like Microsoft, Rackspace.com and the Node.js team are planning on working together port Node.js to Windows.
So, it's not hear yet but it should be soon. w00t!
The Official Node.js Blog
The first stable version has been released: Release details here.
Be sure to check for the latest version as the link above will go out of date.
I'm interested in promoting JRuby in our office as the platform hosting Rails applications.
But how reliable is it?
Is its performance better than MRI 1.8.7?
JRuby 1.5 states that it is 100% compatible with Ruby 1.8.7, does this mean that JRuby can run any Ruby/Rails code?
Yes, JRuby is reliable! Oracle uses JRuby for Oracle mix (http://mix.oracle.com/), Sun had used it for Kenai (http://kenai.com), and it's gonna be the next base for java.net (from kenai site: "Work is on-going for migrating the Java.net domain over to the Kenai infrastructure")!!
You can run almost every code, some gems uses native C extension and in JRuby there's a primitive support to it, but yes...rails just works.
You can deploy Rails apps in Application Servers like Tomcat or JBoss with Warbler that wraps Rails apps inside a .war file, it's pretty awesome!
update: you can see a lot of benchmarks here: http://programmingzen.com/2010/07/19/the-great-ruby-shootout-july-2010/
I am doing a lot of jruby work right now and can tell you that rails is certainly a viable option under the jruby interpreter. I've been pretty pleased and in my case have to use many native Java libraries, so jRuby is just such an awesome wrapper around that java code. I will say that I have had some technical challenges some that are worked out, some that are not yet.
unit testing: spooling up the jvm and then spooling up rails takes much longer, so your tests take longer to run - solution, potentially something like nailgun that keeps the jvm running
deployment: i have not gotten warbler to work for me, with my flavor of tomcat. this is a major issue for us.
pick your libraries, while some c extensions work, they are not all equally compatible.
if you are interested I would highly reccomend the jruby book, in beta, from Pragmantic Programmers at http://pragprog.com
JRuby rocks!! The simple reason being its portability features and integration with Java libraries. I personally use it with Netbeans and the fast debugger that comes with that seems very handly. Plus you do not want to see that native build errors and handling them. All these gems that you download for JRuby work 100% across any platform. With JRuby, you are simply bringing in the advantages of the Java's Platform independence.
Moreover, JRuby uses native threading which uses OS threads instead of Green threads as in CRuby (i think its not the case with the latest versions though)
In Gist, go JRuby!!
for windows I have found it to be much more stable than MRI when working with larger amounts of data. There are some bugs on windows still but they are actually work-around-able. Recommend.
Disclaimer: I don't use jruby in my day job - I merely experimented with running existing code using jruby.
It doesn't mean that it'll run all code successfully. For example, bioruby currently calls fork on jruby even though jruby doesn't really support it. (That's more of a bug in bioruby than a bug in jruby though)
I wouldn't call such behaviour "unreliable" though. It's fail-safe, like a plane that would not get off the ground, much less crash.