In the context of Java 8 and Nashorn I see two projects being regularly mentioned.
Avatar.js and Project Avatar
What is the relation of these projects?
Avatar.js has very little documentation. As far as I gathered it offers the possibility to execute node applications on the JVM.
Project Avatar seems to build on Avatar.js. However the scope seems to be to provide an alternative Web-Framework for Java EE 7. Is it also possible to execute node programs (like i.e. grunt) with Project Avatar?
Update: Project Avatar was officially halted 2015-02-12.
Avatar.js is the open-source version of what was informally called 'node.jar' (See this post from the avatar-js mailing list). In other words, it is a NodeJS-compatible API, running on Nashorn. Project Avatar appears to be Oracle's answer to the NodeJS API, offering an alternative platform which also provides compatibility with the NodeJS API and ecosystem via Avatar.js.
Therefore it is not that Project Avatar is built on Avatar.js, but rather that "Avatar.js is one component of Project Avatar. Nashorn is the JavaScript engine used to run both." (again, from this post).
The Avatar.js homepage currently has a list of modules known to run, including "grunt". It would appear that Project Avatar currently includes a build of Avatar.js as "avatar-js.jar", as found in the current latest commit, though it is 4 months old. So I think the answer is that yes, the current build of Project Avatar will allow you to run Node-compatible modules.
As you've pointed out, both of these initiatives lack documentation, and are in their infancy. Time and community engagement will show where they fit best.
Indeed there is Avatar.js included in Project Avatar.
By looking at the Maven POM files of Project Avatar, I discovered that there is a binary distribution of Avatar.js available through the java.net Maven repository.
Based on this discovery I wrote a blog post how to run simple Node.js apps with Avatar.js here:
Running Node.js applications on the JVM with Nashorn and Java 8
Steps for OSX repeated here:
Download avatar-js.jar from the java.net Maven Repo. Current version
is here:
https://maven.java.net/content/repositories/public/com/oracle/avatar-js/0.10.25-SNAPSHOT/
Example file: avatar-js-0.10.25-20140313.063039-43.jar
Download the native library avatar-js.dylib from the java.net Maven
Repo. Current version is here:
https://maven.java.net/content/repositories/public/com/oracle/libavatar-js-macosx-x64/0.10.25-SNAPSHOT/
Example file:libavatar-js-macosx-x64-0.10.25-20140312.062209-35.dylib
For Linux
you would download the corresponding .so file from ../libavatar-js-linux-x64/0.10.25-SNAPSHOT/
For Windows you would
download the corresponding .dll file from
../libavatar-js-win-x64/0.10.25-SNAPSHOT/
Rename the native library to avatar-js.dylib and rename the jar to
avatar-js.jar and put both in a directory called dist.
Create a simple Node.js app in the a file called app.js.
Run the command: java -Djava.library.path=dist -jar dist/avatar-js.jar app.js
Project Avatar does indeed layer on top of Avatar.js; the code is integrated into our build using Maven. (The jar you found, Johann, was old because we no longer use it -- I just nuked it, thanks).
And yes, we're aware that our docs need more work. For now, we are focussing on fleshing out the server-side JavaScript framework. This services layer provides a runtime tuned for easily creating REST, WebSocket and Server-Sent Event endpoints.
Related
I'm currently following this tutorial: https://openjfx.io/openjfx-docs/ (JavaFX and IntelliJ IDEA). I use Intellij 2021.3.2.
I have created a project (1. Create a JavaFX project), which worked out great and didn't need to 2. Set JDK 16 because it was already set to 17 (which I guess is fine).
But here begin the weird stuff (and I'm very new to programming so I'm sorry if it sounds silly). "You can also set the language level to 11 or greater." I don't have this option. Because it's "can" I felt like it wasn't a big deal but if someone can explain what this is all about? Just out of curiosity, because I'm at the very beginning of the tutorial and I kinda only understand half of it.
Then 3. Create a library, and I don't have what they have, and my stuff is red:
So when they said "add the JavaFX 17 SDK as a library to the project" I didn't know what to do. I also didn't know what to do to fix the red stuff.
And finally, they say "Warning: If you run now the project it will compile but you will get this error: ..." but if I click on this button
everything works! which you know i'm not complaining about but I would like to understand a bit more what is happening.
And then they suggest I should 4. Add VM options to fix the problem that I don't have. So I figured maybe my computer set the VM options correctly without me knowing it but there is currently no VM option (and it works). Should I add them nonetheless?
Thank you for your help, I'm very lost and feel like I don't really understand anything.
The current documentation in the openjfx tutorial for getting started with JavaFX using Idea is incorrect, at least for recent Idea releases (2021.3 +).
The tutorial is written as though a new Java project was created, rather than a new JavaFX project. Once a new JavaFX project has been created, most of the rest of the steps in the tutorial are either redundant or wrong.
Step 1, “Create a JavaFX project", does a lot more than just “Create a Java project”, which is why everything else is different from the tutorial.
A better tutorial for getting started with JavaFX with Idea, is the official Idea documentation:
Create a new JavaFX project.
Differences between creating a new Java project and creating a new JavaFX project
The new JavaFX project:
Provides a build script for Maven (pom.xml) or Gradle (build.gradle).
Adds the appropriate dependencies for JavaFX base, graphics, controls and fxml.
Provides an example application and controller code that you can run immediately.
The example project is modular and provides a module-info.java
Because the program is modular and dependencies are downloaded via maven and recognized by the IDE, you don’t need to manually configure VM runtime options for the module path and adding modules.
Idea will recognize the Maven or Gradle projects and automatically synchronize the initial transitive dependent libraries with the Idea project.
There are options in the Idea Maven tool window which will allow you to synchronize further changes to dependent libraries or javadoc and source code in libraries.
Selects a JDK and attaches it to the project, automatically downloading the selected JDK version if not already present.
Sets an appropriate language level for the project.
When you just use the create new Java Project option, it doesn’t do any of those things, so you need to do things manually instead, which is what the rest of that tutorial is about:
Manually download the JDK and configure it in the SDK.
Manually download the JavaFX SDK and add the libraries from it to your project.
Manually configure VM modular arguments.
Manually maintain any other dependencies.
Manually associate javadoc and source code.
Manually write the code for a basic application.
Manually set the project language level.
Doing all this stuff manually is more work and more error prone. The manual work usually leads to a worse outcome and a project that is more difficult to maintain for many people getting started with JavaFX, so I do not recommend it.
Versions
In terms of the versions to use, I recommend using the most recent stable (non-beta) releases of both JDK and JavaFX, regardless of what versions may be referenced in any tutorials you may be using.
You can set JavaFX versions in the Maven file generated by the new JavaFX project wizard, then press the button in the Maven Tool window to synchronize the Maven project with the Idea project.
Language level settings
These are important later on, but pretty irrelevant when just getting started.
The language level settings:
Tell the compiler what version of the java byte code to compile the application to.
Tell the IDE what language syntax rules to enforce and provide help with.
If you use Java 17 only features, the app won’t run on a Java 11 VM.
You can define the settings in Idea manually:
language setting level.
But it is better to set them in the compiler section of the maven project and synchronize the project with Idea, which will also configure the settings in the IDE.
IMO, set it to the most recent stable version and have a requirement that your application be run with that Java version as a minimum (you can enforce that by using jlink or jpackage to bundle the JRE version you choose with your packaged app).
Is there a way in cloundfoundry to combine two runtime environments? I am deploying a NodeJS app to IBM Bluemix. Now, i also want to be able to execute a standalone jar file but the app fails
APP/0/bin/sh: 1: java: not found
which i guess makes sense as the app was deployed with a Nodejs SDK runtime. I tried to look at some resources
https://docs.cloudfoundry.org/adminguide/buildpacks.html
and
https://developer.ibm.com/answers/questions/16115/use-multiple-buildpacks-on-your-app.html
but I could not understand much yet. Is there a straightforward way to have both the NodeJS and Java runtime in a Bluemix app?
In short - you need to create custom buildpack and use it for application deployment or grab one of the community combined buildpacks.
Have a look on https://github.com/syahrul-aiman/nodejs-java-buildpack for example.
If you don't want to mess with forking a build pack, which is an ongoing maintenance burden, you could try using this multi build pack or the fork of the old Heroku multi build pack. These both let you specify multiple build packs to run, so in your case you'd include both the Java build pack and the NodeJS build pack (they'll run in that order).
There is also currently a proposal for the platform to support multi build packs natively. You can see that here. When this is available, it will remove the need to use the multi build pack, build packs above.
We've updated our buildserver (Atlassian Bamboo) to Java 8 (JDK).
Since then our integrationtests are failing because our started product does not open any port.
We are building with maven and as part of the integrationtest we are starting our builded product. Our product is a Rest-Api based in an OSGI (equinox) and Jetty.
I tried a lot of things, but nothing helped me to get the product start properly in the maven build.
When I log in on my remote machine and start the product manually everything works fine.
Some more information:
Our buildserver runs as a windows service and our product is written in plain Java.
Presumably you are affected by one or more of the issues discussed in Custom AMIs will not start anymore in Bamboo Cloud (BAM-16291), notably that Bamboo is not compatible with JDK8u60 yet:
Joda-time, one of the libraries used by Bamboo is not compatible with
8u60. We've fixed this problem, but the fix has not been rolled out
yet. Known breakages include S3 interaction and CodeDeploy plugin.
Most/All participants got things working again by downgrading to JDK8u45, as also recommended in Atlassian's most recent update:
Use JDK 8u45. The latest JDKs are incompatible with some 3rd party libraries we're using.
Try to match the layout and scripts of our stock images as closely as possible. This will make it easier for us to provide help if
anything goes wrong.
Choose Oracle if you have the choice between Oracle and OpenJDK flavor of JDK.
Back in the old times, the Sun Java dev. toolkit (v2.x) used to have a stub generator tool, but no longer in 3.x versions. I can still use the old generator, but it is very picky when it comes to input WSDL files, and the errors generated do not contain any useful info to fix the WSDLs. The company that develops the SOAP WS is providing me with WSDLs not compatible with JSR-172, and I need to prove I'm using the the last official tool available to show there's no problem on our side.
I have installed the last reliable version of JavaME SDK (3.4) available at Oracle's site. These 3.x versions do not include an IDE, instead they provide plugins for Netbeans and Eclipse. I'm an Eclipse person, but I've opted for the Netbeans approach because looks easier to configure.
So I've downloaded the last Netbeans version (7.4). I've downloaded the bare-minimum JavaSE only version, then installed the mobility plugin for JavaME (Last time I needed to install Netbeans, you had to install the full JavaEE IDE plus GlashFish servers, etc. So glad to know they now offer the option not to install the full IDE).
Added the JavaME SDK v3.4 in platforms, but it does not detect it automatically. I was forced to configure a custom platform, but then the ant build failed. To solve this, I've installed the JavaME SDK v3.2 as well, which is detected by Netbeans out-of-the-box and builds fine.
You might think the stub generator tool would be available by now. Wrong!. You still have to go and install the "SOAP Web Services" netbeans plugin, which in turn installs a ton of other dependent plugins (by now the lightweight JavaSE install has become the bloated JavaEE-ready IDE that Netbeans has always been).
So then I created a basic JavaME project. Right-clicked over Source packages, then selected "New" -> "Java ME Web Services Client". The stub generator dialog is finally shown (and it looks pretty much like the old Sun Java CLDC 2.5.2 tool). I select the WSDL input file, type the client name and package name, and also ticked the "Generate databindings structures" checkbox (which I don't know what the heck it is for, but suffice to say I've tried both w/ and w/o this option selected and the result is the same).
Then I click the Finish button and only a .wsclient file (along with the imported wsdl file) is created. What is the purpose of this file? But most importantly, where are the .java or .class files? They are nowhere in the project folder!
Questions:
Is it possible to generate JSR-172 stubs using Netbeans?
If not, is it possible to do this using the Eclipse JavaME plugin?
It turns out there is a problem with the input WSDLs. They are valid but something is wrong because Netbeans does not generate any java file.
I've tested again with a known good WSDL and it works, so the procedure I followed is correct.
UPDATE:
I was using a local WSDL input file, and due to a bug in the SDK, if the file path contains whitespaces, the stub generation fails. In NetBeans no error is shown.
I have a question regarding the development of liferay portlets using the liferay plugin SDK. My question goes mainly in the setup of the development IDE. The suggested one would be to use Netbeans IDE which I also tried out, but it appears to run very slowly on my machine while Eclipse is quite performant.
The setup for Netbeans IDE is the following
Go to the directory \portlets
Run the create.bat (or sh file depending on the OS) to create a new sample portlet
Run Netbeans IDE, create a new "Java free form project" and point it to the directory of the created sample portlet
That's it, pretty simple.
For the mentioned reasons above (and because I'm a lot more familiar with Eclipse) I'd like to import the project into Eclipse the same way. Is there a way for doing it without having to change too much in the original structure of the created sample portlet and the according build.xml (ant file)?? I tried already to create a new project out of the build.xml ant file of the created sample portlet, however in this way it doesn't include me the source code.
I didn't also find great tutorials on the web...
Could someone help me with this, pointing out online tutorials or give me some hints.
Thanks
I know your pain. Starting to work with Liferay needs much time. I you do not want to edit the existing source, but only crate your own portlets, you can download the plugins SDK from the 'Additional Files' section on the Liferay website. This provides ant scripts, to create a simple JSR compliant portlet, and to create all necessary things, to create a sound Eclipse project, for example:
ant -Dportlet.name=<project name> -Dportlet.display.name="<portlet title>" create
Than cd into the directory of your created portlet an do:
ant setup-eclipse
After that you should be able to create a new project from the sources in that directory in Eclipse, which can then be deployed via another ant script to the running tomcat instance. If you already know somthing about portlet programming, you shoud be pretty much settled now. If not, try to find documentation about JSR portlet programming first, before looking into Liferay specifig portlet development.
Liferay has now released an official set of Eclipse plugins that support portlet development. Here is the installation guide for installing the eclipse plugins:
Liferay IDE Installation Guide
Also there is a getting started guide that shows what to do after installation to actually setting up your first portlet project.
Getting Started Tutorial
Liferay IDE uses the Plugins SDK from Liferay under the covers to do all the work. If you already have existing projects that you created with the Plugins SDK those can be imported into Liferay IDE as well.
Importing existing Projects
you can find the tutorial for deploying liferay in eclipse
http://www.liferay.com/web/guest/community/wiki/-/wiki/Main/Development+Environment+(Windows)
No clue about Liferay's specifics, but in general, I'd do this:
Follow the steps 1 and 2 from your NB setup list
Create a new Dynamic web project (or a Java project if you don't need the web project's features) in Eclipse
Import the contents of sample portlet directory by doing Import -> File system in Eclipse
Adjust the project's Java source directory to point to the generated sample portlet source directory (that should now appear in your project)
Adjust classpath of the project, point it to LR lib folders, ...
If there's a generated build.xml, check if it can be used to deploy to LR, or to produce builds.
As of March 2011, there is some official Liferay support for NetBeans and as noted before, there is official support for Eclipse ( In the Marketplace). The Documentarian uses Eclipse himself, though many examples just use the Plugins-SDK with shell scripts, ant scripts and no IDE.
We are fighting with Liferay on Eclipse, Eclipse seems buggy and unpredictable, but we are also new to J2EE and Eclipse ( so discount this last comment a bit), and I have our portlet files setup in a separate area for SVN, requiring a refactor-move, refactor is definitely buggy.
You should be aware that there is a book for developers on the way from the official documentarian - we've bought the early release and found it useful. He does cover some IDE issues. See Manning press.
The Liferay sample portlets ( there are many) are not set up for Eclipse projects, and you'll have to import some java files and jump through some Eclipse hoops to get them into a running Eclipse project you can develop.