Can anyone advise on the main benefits of installing the Tomcat native library?
I am running a standard installation of Tomcat to serve a moderately complex intranet based web app using Ext Js on the front end so lots of javascript and AJAX over the network and VPN from various locations.
Is it even worth installing this library for the comparatively small amount of requests it will be getting.
The app can be very slow at times and I'm looking to boost performance. I am already refactoring Java code based on profile data but as the problem seems to be more generalised I am also looking at the app server configuration and I can't seem to find any detail on whether this library would actually benefit me in this scenario.
Thank you
I assume you are speaking about Tomcat APR. I personally don't believe that by simply switching the connector from non-native to native will automagically solve your performance problems.
Unless you have exercised all code inefficiencies (it seems that you are doing this already with the help of profiler) and solved them, it is probably not worth it.
I would envisage that APR helps in cases where most of requests are static and delivering static content becomes a bottleneck. To achieve this, you probably need to be delivering millions pages per day and having thread pool going through the roof (which I assume is not likely for your intranet).
Some of tomcat apr is not found in ubuntu repositories as they are no longer supported.
Please make sure these configurations are correct:
In eclipse under windows->preferences->servers-> runtime environment,
choose the server where your project is deployed. Select the option installed jre and choose the java version you have installed or one you prefer.
Under project properties -> runtime environment select the server and press apply.
Under build path double click on jre library and choose the java version you have installed.
Native libraries are required when there is a mismatch between the code in the project in the jre version or the tomacat version.
Make sure that in your build and code, both are for the latest version of servlet that tomcat supports and jre is at its latest version that tomcat supports.
For example, if tomcat v8.5 supports java version 7 or above, you should have java version latest above 7 and tomcat v8.5 supports servlet version 3.1 so in your build set up. Make sure to use a container that uses servlet 3.1.
Related
Migrating server from microProfile-4.1 to microProfile-5.0 and based on https://openliberty.io/blog/2021/11/26/jakarta-ee-9.1.html, I map wasJmsClient-2.0 to messagingClient-3.0 and wasJmsServer-1.0 to messagingServer-3.0.
<featureManager>
<feature>microprofile-5.0</feature>
<feature>messagingServer-3.0</feature>
<feature>messagingClient-3.0</feature>
</featureManager>
The server seems not able to start reporting some conflicting versions of features.
From what I understand all are Jakarta EE 9.1 compatible but if not what are the best option to replace wasJmsClient-2.0 and wasJmsServer-1.0 ?
Yes this should work. I am not sure how you are installing liberty and the features which could make a difference. There were some issues with installing of features not including all dependent features earlier this year. So I would ask that you include what version of liberty you are using and how you installed it and possibly how you installed the features. I just tried with the latest code and it started up cleanly for me. So if you can also provide details about what the error message looks like that would be helpful.
My question is similar to the one asked in this forum in 2010 - "is JRE installed in Windows & Linux?". And I am wondering if things have changed since then
In particular, my site hosts a downloadable Java application that basically transmits specific files from the user's PC to our server. But every now and then I find that some of my users - all non-techies - don't have JRE installed. And hence, I have to ask them to install JRE first.
Asking users to download something before they can start using my application can only ruin the end user experience. Understandably, that is a no-no. And so, I am ready to re-implement the application. But before I can propose re-implementing the app in some other technology - like Qt - I need facts to make a case. In particular, I would like to know
Is it safe to assume that any PC with an OS that is XP or above would have JRE installed on it?
Is Qt a viable - and preferable - option for making a "download-now-use-now" type of application? Don't Qt applications need a JRE equivalent too?
Are Qt applications able to update themselves like Java apps can?
Other than having to maintain/compile multiple versions of Qt, are there any other disadvantages to using Qt?
Thanks for your responses
Abhinav
No, it is still not safe to assume that every machine had the JRE installed, though it is easy to install for every machine.from the Java website. Java is not installed by default on any Windows computer but I believe it is installed by default in many Linux distributions.
Qt is a GUI front end system for other programming languages. I know of Qt implementations for C, Python and now Java. If you are intending to use Java Qt then you will need to use the JRE to run it, it is not a way to get around restrictions of Java but is instead a way to make applications look consistent even though they are written in different languages.
A Java Qt application will have the same abilities as a normal Java application in terms of updating.
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.
Starting with the next version of Mac OS X, Java will no longer be included in the system and I don't want to force my customers to install it themselves. So I would like to do what I do on Windows - bundle it with my app. It also gives me some hope that it could get included in the Mac App Store.
Where can I download a Mac OS X JRE that I could include with my application? Or can I just copy the one that's installed on my Mac?
Update (4/15/2013):
As Thorbjørn helpfully pointed out, Oracle now has a solution for this. See http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/packagingAppsForMac.html. However, I'm keeping the original content for "historical purposes", and because it was a fun research project.
Previous version (with edits):
This is a great question. I was going to respond that you are simply ahead of your time -- as you pointed out, Java is not going to be removed until the Lion release. However, this article makes it clear that using Java today is not allowed:
Apps that use deprecated or optionally installed technologies (e.g., Java, [PowerPC code requiring] Rosetta) will be rejected.
At the same time, no one has announced a redistributable JRE for Mac OS X yet. I think your best bet, bearing in mind that you are forging new ground, is to check out the Mac OS X Port wiki page of the OpenJDK project. It does describe how to compile your own JDK, but it does not clearly state whether or not the resulting JDK can be "bundled" cleanly or not. I think you will have to try it and see :-(.
Also, it's not clear if the OpenJDK licensing allows this at all (IANAL). Hopefully someone else has already figured this out with regard to Linux/Windows, although of course the rules may be different for the Apple contributions.
Hope this helps. If nothing else, it's a starting point.
EDIT: I am going to throw out one additional suggestion. We now know that Mono apps can be packaged for the App Store. Furthermore, IKVM.NET is a complete implementation of Java that runs on top of Mono. You could try, in theory, to put these two pieces together and get a Java app, bundled for the App Store, that does not in fact require a JRE!
If you try this, I would love to hear how it works out :-).
EDIT 2: Unfortunately, the App Store and the GPL do not appear to be compatible (see http://www.zdnet.com/blog/open-source/no-gpl-apps-for-apples-app-store/8046). The OpenJDK license isn't exactly the same as the GPL, but it's pretty close (again, IANAL). Therefore, Mono & IKVM.NET may be your best bet. Good luck!
In the same web search that I found this question, I've found the these instructions from the OpenJDK project. Not having tried them myself, I cannot comment on how well they work.
Meanwhile, another, very detailled article was published by Marco Dinacci which also goes into signing and sandboxing.
Apple has joined the Sun/Oracle OpenJDK open source project last month, so Java on Apple is alive and kicking.
Just tell the user to download and install the OpenJDK JRE for Mac OSX (when it becomes available, right now it´s just source code).
And no. you cannot include "the folder that is in your mac" without permission as it is copyrighted code from Apple.
Finally, packaging a "private JRE" is a very bad practice, it will make your app bloated, andif the user ends up running several Java apps, he will end up running multiple Java VMs simultaneously which is a terrible waste of system resources.
Does Mac App Store accept application written in Python/Java/Ruby?
The Good News
Yes, you can submit a Java app to the Mac App Store. Not true in the past, but it is true at least as of now in 2013.
One example is the successful MoneyDance personal finance app currently available for sale in the Mac App Store.
The Bad News
Preparing and submitting your app is neither simple nor easy. You have to jump through some hoops.
Your app cannot depend on Java being installed on the Mac. You must include a JRE (Java Runtime Environment) within your Mac app.
You must write a thin Objective-C wrapper around your Java app. The source code and examples/tutorials are available on the web.
Like any other app, you must go through all hassle of the complicated build and deployment rigmarole with security restrictions Apple requires of any Mac App Store app.
More Info
Two articles, Take your Java application to the Mac App Store and Forking the OpenJDK for fun and profit, by Marco Dinacci. These articles may provide other useful information, but fortunately their discussion of forking the JDK is now outmoded. He and others have provided the needed patches now incorporated in the official releases.
How to Create a Mac OS X Installer for a Java Application (Updated for Mac OS X 10.8 — Mountain Lion) by Dem Pilafian of Center Key Software.
Packaging a Java App for Distribution on a Mac (Oracle)
Submitting to the Mac App Store (Apple)
By the way, you can use both Swing and JavaFX in your app. JavaFX is now bundled with Java, at least as of Java 7 Update 40 according to these Release Notes.
Java 9
The newly released Java 9 should make this process of wrapping an app with a runtime even easier and better.
Modules
Java 9 brings “modularization”, Java Platform Module System (JPMS), where the approximately 5,000 classes bundled with a JVM are grouped into about a hundred chunks known as modules. You can include only the modules containing classes actually used by your particular app rather hauling along every library. If you don't use JSON or CORBA, then you need not include the JSON or CORBA related modules.
The new jlink tool does this work for you, to assemble and optimize a set of modules and their dependencies into a custom run-time image. As a bonus, some link-time optimization work is performed to make your app launch faster.
These features are supported on 64-bit macOS systems, along with other platforms.
Native compiling
Java 9 also brings new support for native compiling, to build an app optimized for specific hardware. But this ability is experimental, and not yet ready for production use.
Update, as of 2018
Oracle has announced the end of web deployment technology, including Java Web Start, the previously recommended avenue for desktop apps. So now, Oracle expects all Java apps to be delivered bundled with a JVM such as is done with the jlink tool mentioned above.
So, the process of wrapping an app with a Java runtime that was something of a rarity just for the Apple App Store is now mainstream. Oracle expects any Java-based desktop app to be installed this way.
Yes and no. Apple doesn't care what language your App is written in, but it cannot depend on or install anything outside of the binary you submit to Apple. The relevant guidelines are below:
2.14
Apps must be packaged and submitted using Apple's packaging technologies included in Xcode - no third party installers allowed
2.15
Apps must be self-contained, single application installation bundles, and cannot install code or resources in shared locations
2.16
Apps that download or install additional code or resources to add functionality or change their primary purpose will be rejected
So, while this means you can't depend on Ruby or Python, you could use a framework like MacRuby to build your app in Ruby and embed the Ruby interpreter. Speaking for MacRuby, apps have been successfully submitted to the Mac App Store this way.
Ruby ? Yes !
Apple already accepted one of my apps written in MacRuby.
AFAIK, Cocoa will allow you include code written in different languages (including Ruby and Python, but not Java I don't think).
Check the Apple SDK's for more info, but I believe (thanks to Cocoa) it's not a problem.
For Python apps, I wrote a comprehensive article explaining how to build and submit such apps to the Mac App Store. It includes source code and build scripts for a barebones example app that I have successfully submitted.
Submitting a Python App to the Mac App Store
Possibly Java, if you bundle the Java application into a mac application.