I've built plenty of Java webapps that run in standard containers like Tomcat and Jetty, but I've never built one that runs in Google's App Engine before. I'm using Maven, so I had originally thought that I could just do this with build profiles to just optionally include Google's libraries at build time to make an App Engine-compatible WAR.
Unfortunately, it seems to be more complex than that. In reading through the documentation, there seems to be an awful lot of very specific code you have to write in order to use the App Engine. For example, all file system writes need to go through the App Engine data store, so you can't use native java.io.* libraries.
I understand why these things are necessary, and I wouldn't mind having some of this code in my webapp. However, I really don't like the idea that my webapp can only run on the App Engine. Is it possible/feasible to write my code in such a way that I can also run it in a typical container like Tomcat?
It mostly depends on what you app is going to do. You are going to run into troubles as soon as you want to do stuff with the datastore, or caching for example. Perhaps you could wrap things line datastore calls or caching, but certain apis, like search you can forget about. If you just want to run something locally that is no problem you can mock the app engine locally.
Related
I have an application that runs under Java/JNLP applet and I would like to migrate to Java 11.
As you know the applets and JNLP will disappear from Java 11.
The goal is to keep my old code and remove the packages that contain the applets, is it possible to do this migration without switching to a new technology?
Finally, I chose Swing with Getdown which resembles JNLP.
A migration to a JEE/Spring solution would have completely modified the operation of my application and still take a lot of time. Tip: try it for yourself Getdown.
Yes and No.
Yes you can keep your java business logic and data handling code (presumed you did a clean separation of your application layers). E.g. just convert to a standalone java app and you're fine.
No, if you look for something to run in the webbrowser then you have to migrate to JavaScript/HTML/JSF/GWT... on the frontend and your java code running on the backend (JEE or Servlets ...).
Regarding the "No", it depends on what kind of application you have. A web application or a standalone application?
(1) For a web application you have to recreate the front end part (UI, communication with the server) but you can reuse parts of your logic.
(2) For a standalone application (using Swing/AWT/JavaFX ...) you can keep your code, just create a standalone app out of it. For distribution e.g. JavaFX offers an application packaging mechanism.
PS: The quickest way could be the conversion to the webstart technology however it was also deprecated and will be also be removed in future. So I would not use it.
One solution might be the WebStart replacement that Karakun is currently working on: https://dev.karakun.com/webstart/
Currently it is not clear when and how this will come since it is based on a kind of crowd-founding but since everyone can get involved (even with low cost) this is a very good possibility.
I built a large JAVA web application using SPRING & MongoDB,
In some scenarios, I want to allow my users to upload their own code, and the application will run it later on when necessary.
I called this operation "Plugin framework", the plugin is the user's code of course which I prefer to be in NodeJS for now.
There is any recommended / known architecture for that purpose?
I've read about pf4j and senecajs, but they quite different from my needs.
Thanks!
You loose complete control over code running on node. The uploaded code can access network, files, database, you name it. That is not a good plan.
I suggest to work with the embedded JS module in Java, called rhino. Here, you define which environment the code can access.
You find samples of using the scripting in Java here http://docs.oracle.com/javase/7/docs/technotes/guides/scripting/programmer_guide/index.html for jdk7, the Javadocs https://docs.oracle.com/javase/8/docs/api/javax/script/ScriptEngine.html and here some info on Java8 changes http://www.oracle.com/technetwork/articles/java/jf14-nashorn-2126515.html
UPDATE:
On the comment below, you state that you think you are safe, if the code runs on the other server. Actually, the problem is still the same. Just it won't hit your application's server but the JS code server.
My advice stands. Implement a JS execution service using the built-in Javascript engine (Rhino or Nashorn) and restrict the running JS to a sandbox, you control the script's reach out of the box through carefully implemented env-access methods. It is actually pretty easy to get started, no more complicated than implementing a remote javascript implementation engine on top of node...
I am developing an AppEngine application with GWT framework using Java. Objectify as back-end(storage purpose). Application has around 30 modules. Whenever I open any page in my web application, it is too slow to display. I want my application faster.
Please help me out with this nasty problem.
Two back to back steps.
Here is the SpeedTracer
And here is the Optimization Techniques of GWT
as already mentioned above, do this steps in general.
but developing for AppEngine needs thinking for AppEngine.
so also AppEngine Docu:
https://developers.google.com/appengine/kb/java#What_Is_A_Loading_Request
Main stuff: AppEngine is not a Java App Server like, Tomcat, Jboss and so on.
AppEngine is a complete own environment running java, (this you should at latest realize when you downloaded the AppEngine SDK )
and then you should see two options, change your account to billing account, and pay for preloaded App
or better, forgot about third party libs and write it by yourself,
for what you need objectify ??? the appengine datastore api is very good.
using the Apis directly will also point your thinking of how to design your app for AppEngine better.
Use Appstats to profile your application and identity which RPCs are slowing down your app.
Having done this, you should be able to find ways to reduce the number of RPCs you're making, e.g. by using memcache. You could also try to use async APIs wherever possible.
You should think to cache data for the session or across sessions on your client side also. You can do statistics on the most common requests and do server caching on them too
I am quite certain the reason its slow is because your application loads all the code in the browser.
Use HTTP watch tool to see whether this is correct. For a 2MB nocache.js file it usually takes 2 minutes to load.
Are you using any MVP framework on your application; if not, this could be one of the problem. Objectify is not going to slow you application, I presume it is the way you built your application.
Also try to use GWT 2.5, so you can take advantage of the closure compiler so you can reduce you application's footprint for about 20% (maybe). Furthermore if you are deploying in Tomcat, you can try to enable gzip compression.
"Slowness" of an application can't be attributed to just one part of the application, it could be spread across the layers of your application (based on my experience)
Hope this helps.
I used playframework previously. Development with play! is so fast. It has an internal java compiler and all the actlon methods are static. So the result is awesome.
Nowadays i use spring on netbeans. Netbeans has a deploy on save feature. But redeployment time is greater than 10 seconds. I used jrebel. But jrebel does not give the same effect. I used eclipse. Eclipse is worst than netbeans. Why java development should be so difficult? Is there any method for fast redeployment?
You have already mentioned JRebel. There are other options, but they are not faster. For example, WTP plugin for Eclipse. You can use jetty-maven plugin, you can use emended jetty-server for development. You can use file-sync plugin for Eclipse. This is 3 most popular and fastest way to deploy project. But all of them require redeploy of server.
You will never get this speed like Play framework or some dynamic compiler language. But probably it's not necessary ?
If you change static resources, like jsp, js, css, you don't need deploy. If you change Java code, just test your code with JUnit or something else. Or write a bunch of code and make deploy
IMHO the more experience you gain, rarely you make deploy =) You don't need to check, what's going on, because you know exactly, what you are doing =)
The reason why Play deployment is so fast, is that it isn't an actual deployment in the original sense of the word. Play checks for the modifications in your Java code, then takes just that file and compiles it and changes the state of the JVM to incorporate the new class.
A real deployment to an application server or event to "just" a servlet container is more than that. The package (war, ear) has to be expanded. Internal structures of the app server has to be updated and the app has to be started. This all takes time because much more components are working together.
What Java web development environment is the best for absolutely minimizing the build-deploy-test cycle time?
Web development environment: JBOSS, Tomcat, Jetty? Deploy WAR exploded? Copy WAR or use symbolic links? There are factors here I don't know about.
Build-deploy-test cycle? The amount of time it takes to test a change in the browser after making a change to the source code or other resources (including Java source, HTML, JSP, JS, images, etc.).
I am looking to speed up my development by reducing the amount of time I spend watching Ant builds and J2EE containers start. I want the Ruby on Rails experience --- or as close as I can get.
I'd prefer a solution that is web framework agnostic, however if a particular framework is particularly advantageous, then I'd like to hear about it.
Assume all the standard tools are in use: Hibernate, Spring, JMS, etc. If stubbing/mocking support infrastructure is required to make this work, I'm OK with that. In fact, I'm OK with having a development environment that is very different from our production environment if it saves me enough time.
You should probably take a look at Javarebel:
http://www.zeroturnaround.com/javarebel/
and this thread here:
How to improve productivity when developing Java EE based web applications
JBOSS uses Tomcat for its servlet/JSP engine, so that's a wash.
Tomcat does support hot deploy.
Jetty's pretty small and starts quickly, but it doesn't support hot deploy.
Eclipse is merely an IDE. It needs a servlet/JSP engine of some kind. If it's like IntelliJ, you can use any Java EE app server or servlet/JSP engine you'd like.
IntelliJ is pretty darned fast, and you don't have to stop and start the server every time you rebuild. It works off the exploded WAR, so things happen fast.
Building (used to be compiling) is a a sign of our times. We need quick validation of our thoughts and our actions. Whenever I find myself building to many times it is usually a sign that I'm not focused. That I don't have a plan. For me this is the time to stop and think. Do a list of things that need to be done (this is web framework agnostic) do them all and test them all after one build.
Jboss Seam together with the Jboss Developer Studio is good for hot deploying everything aside from EJBs (SLSB, SFSB and Entities need redeploy).
Have you considered Grails?
Deployment is as fast as it can get with Google App-Engine + GWT (optional) + Eclipse Plugin.
Never seen anything faster.
Maven 2 and eclipse. mvn eclipse:eclipse <- pure awesomeness. Also, WTP within eclipse works great (and maven generates working WTP projects).
Small web containers will load faster than overloaded webcontainers with the kitchen sink built in (.. cough .. jboss ).
Some design decisions slow build times (e.g. aspect-weaving based toolkits add an aspect-weaving phase to compile times).
Avoid building components that can only be tested after long elaborate load cycles. Caches are a prime culprit here. If your system has deep dependencies on a global cache scattered everywhere you'll need to load the cache every time you need to test something.
Unit-testable components, so you can run pieces instead of the whole thing.
I find that projects built reasonably compile, deploy, and startup in a few to 10 seconds, which is usually fine.
GWT in eclipse is probably the fastest I can think of. Using the hosted mode browser for your tests you can debug and change your code without restarting anything. Just need to click the refresh button in the browser and the changes are there (java, css, etc). One other thing is that GWT is adding this same support to normal browsers (Firefox, IE, Safari) so you can debug from within them the same way. These changes are coming in 2.0. See http://code.google.com/events/io/sessions/GwtPreviewGoogleWebToolkit2.html
Have you tried using Eclipse Java EE and then tell it to deploy to a server managed by Eclipse? Tomcat and JBOss works pretty well in this way. Also allow you to change code in a method, use Ctrl-S and have the class updated inside the server.
MyEclipse also works pretty well like this.
JRuby on Rails. Develop on whatever platform you want, deploy to standard Java servers.
I think the best way to avoid the long build deploy tests cycles is writing unit tests for your code. This way you can find bugs without waiting for the build/deploy phases.
For JSP you can edit the JSP files directly in the JBOSS work folder:
> cd $JBOSS_HOME/server/default/tmp
> find -name myJspFile.jsp
./tmp/vfs/automountd798af2a1b44fc64/Jee6Demo.war-bafecc49fc594b00/myJspFile.jsp
If you edit the file in the tmp folder you can test your changes just hitting the browser refresh button.