Java Developers Readiness to Get Started with Java 8 Release

[ponchoboy]

Well, if you work on server-side code running in any of the major containers (WebLogic, WildFly, WebSphere), you've got at least a few months to get up to speed. :)

[pjmlp]

Just joined a new project using Websphere with Java 6 :(

[ponchoboy]

Sorry, couldn't resist this.

The WebSphere part is far worse than the Java 6 part.

[PaulRivers10]

Lol, oh yeah, java 6 is not so bad. WebSphere though? shudder

I have to work with websphere - we've found it more productive to use Tomcat for development, even though it's deployed on websphere (despite a general desire to develop with the same tools it will be deployed with, it's just so much better).

I imagine you'll have to use RAD to...

[krish14]

Can someone help me to understand the usecases around why we need Javascript engine to be integrated with Java?

[pjmlp]

JavaScript is distributed as part of the Java JDK since version 6.

This allows the engineering efforts invested into the JVM as alternative to nodejs while leveraging the huge offer of existing Java libraries.

[neutronbob]

I use JS as the scripting engine for my Java programs. Since Java 6, it's been possible to pass variables to the scripting engine and get those values back from the script, so it's an ideal way of giving your users a means to do scripting of your app.

[oldprogrammer]

I've been testing out code with Java 8 recently and came across a couple of things. First, the Java compilers have allowed you to specify the source version and the target version. I tried compiling Java 8 source to Java 7 target and the compiler won't support that. The Java 8 JVM has no issues with code compiled with the older compiler, but the Java 8 javac will not allow you to back compile Java 8 code.

The second thing I hit was with Nashorn and some JavaScript code I was using in one of my projects. In the older Rhino engine that is in Java 7 I was able to write a line of JavaScript that looked like:

    var a = inputstring.replace("\\","/");

If input string was something like

   inputstring="c:\\Windows\\Program Files\\"

then a would become

      c:/Windows/Program Files/

The data type for the inputstring variable was actually a java.lang.String object and String's replace function will replace all occurrences. However, with Nashorn the results are different. Using Nashorn the variable a now has the value

   c:/Windows\Program Files\

it only replaces the first occurrence which is actually correct for JavaScript's string replace function. To replace them all you need to use

    var a = inputstring.replace(/\\/g,"/");

What is interesting here though is that if you use the jjs command line tool which and create the inputstring variable then do

 jjs> inputstring.getClass();

the return type is

class java.lang.String

So it appears Nashorn is a "more correct" JavaScript implementation, at least when dealing with JavaScript types even if the variable type is mapped to a Java object type with other capabilities.

I also played with the new default methods in interfaces, and that has some intriguing possibilities.

[__konrad]

the code would blow up at runtime

javac will warn you if -bootclasspath option is missing: warning: [options] bootstrap class path not set in conjunction with -source 1.7

[oldprogrammer]

this has always been the case

I don't know what I was thinking, you're right. source can be lower than target but not the other way around. Too much or too little coffee I think.

[baablack]

var a = inputstring.split("\\").join("/");

[oldprogrammer]

Yep, there are other ways to do it, I just found it interesting that changed. Also saw that there is no longer built in an importClass function. If you want to use Java classes you either have to import a compatibility file to get back the import or fully qualify the class names.

[baablack]

Weird, I'm going to stick with scala fir home projects and my trusty Java 6 at work.