Sencha Cmd - Future Java Version Requirements

[dongryphon]

Hi All -

We are evaluating Java 7 API's for some of the upcoming new features of Sencha Cmd and wanted to get some feedback from you, the community, about the potential impact of requiring JRE 7. We realize many or maybe most of you have current JRE's but this is not always the case in some corporate contexts.

The release of JRE 7u4 is most important to Sencha Cmd due to the inclusion of Java FX 2.1 with its Webview based on WebKit (see http://www.drdobbs.com/jvm/java-7u4-...-712/232901064).

In general, however, Java 7's new FileSystem API is also potentially very useful for things like file system monitoring.

Your feedback is most welcome.

Best,
Don

[dmulcahey]

My 2 cents on this...

I work for an Insurance Co. And we're pretty far behind. 1.6 U30 is our standard at the moment. That being said, I say go for it. I am running Jenkins, Artifactory and some other tools off of custom build servers and we are keeping those up to date (newest release of 1.7). The version Cmd uses shouldn't concern many people seeing as its a build time requirement and not a runtime requirement.

[dongryphon]

Thanks for the feedback. Indeed the nature of Sencha Cmd does give it some latitude there.

[sonata82]

Imho 1.6 would be the way to go.

We are deploying our application for Java 1.6.x and for consistency reasons, compiling and building is done using the same Java version. Requiring 1.7 just for Sencha Cmd would be a showstopper for us.

[dongryphon]

Imho 1.6 would be the way to go.

We are deploying our application for Java 1.6.x and for consistency reasons, compiling and building is done using the same Java version. Requiring 1.7 just for Sencha Cmd would be a showstopper for us.

Not to debate your reasons, but I am curious why 1.6 was chosen.

[sonata82]

Not to debate your reasons, but I am curious why 1.6 was chosen.

When the project started two years ago, Java 1.6 looked like a version which was in a stable enough state to use it (we are developing for IBM i). Originally we even started on Java 1.5, to keep the requirements for our customers as low as possible, but pretty soon moved to 1.6, primarly to get support for JAXB 2.0 and StAX.

[phas]

i ssh to one random server of ours and

tesole@ks312811:~/repo/tesolevents/tesolevents/tesolepanel$ apt-cache search jredocbook-jrefentry - DocBook XML JRefEntry DTD
docbook-xsl - stylesheets for processing DocBook XML files to various output formats
default-jre-headless - Standard Java or Java compatible Runtime (headless)
default-jre - Standard Java or Java compatible Runtime
libjrexx-java - automaton based regular expression API for java
kaffe - A JVM to run Java bytecode
openjdk-6-jre-headless - OpenJDK Java runtime, using Hotspot JIT (headless)
openjdk-6-jre-lib - OpenJDK Java runtime (architecture independent libraries)
openjdk-6-jre - OpenJDK Java runtime, using Hotspot JIT
openoffice.org - OpenOffice.org Office suite
ia32-sun-java5-bin - Sun Java(TM) Runtime Environment (JRE) 5.0 (32-bit)
sun-java5-bin - Sun Java(TM) Runtime Environment (JRE) 5.0 (architecture dependent files)
sun-java5-fonts - Lucida TrueType fonts (from the Sun JRE)
sun-java5-jre - Sun Java(TM) Runtime Environment (JRE) 5.0 (architecture independent files)
ia32-sun-java6-bin - Sun Java(TM) Runtime Environment (JRE) 6 (32-bit)
sun-java6-bin - Sun Java(TM) Runtime Environment (JRE) 6 (architecture dependent files)
sun-java6-fonts - Lucida TrueType fonts (from the Sun JRE)
sun-java6-jre - Sun Java(TM) Runtime Environment (JRE) 6 (architecture independent files)
sun-java6-plugin - The Java(TM) Plug-in, Java SE 6

this is my feedback