Has anyone built DCEVM dll for jdk9 yet? This is very efficient JVM with a drawback for missing G1 gc (uses only serial GC atm). I was hoping to get some tips on how to build it for java9.
Regards,
I got a response from a PCM. It's in here.
AdoptOpenJDK/openjdk-jdk9
The only reason it's slightly different is because the top search page for DCEVM on github.io doesn't mention anything on Java 9. Only Java 8. I have requested the PCM members to provide some link for Java 9 on dcevm.github.io.
Related
I have an application written on Java SE 8 that was heavily using features for mixing Heavyweight and Lightweight components.
In particular, the function "SetComponentMixingCutoutShape" was used, which was later deprecated in future versions of Java.
Now I have an option to switch to Java 11 - and I run into a problem. Seemingly, there's simply no alternative for this functionality in later versions of Java. Or at least I couldn't find one.
So what does that mean - that I simply don't have access to that feature AT ALL anymore?
Thanks for replies!
As soon as I asked I found the answer.
The functionality has been moved to component class
Before you used to call setComponentMinxngCutoutShape(component, shape);
Now you need to go component.setMixingCutoutShape(shape);
I want to know whether the official Java core API is part of JDK or JRE.
According to my understanding of Java, I think that the core API should be part of the JRE, as the application should be runnable without the additions provided by the JDK.
I also found some information on the web that says the 3 basic components of the JDK are,
Java Compiler
JVM
Java API
(As the JRE is the implementation of JVM, does the Java API belong to JRE or JDK?)
Edit: actual question: Is the Java API included in JRE?
Your facts are a bit inaccurate.
I also found some information on the web that says the 3 basic components of the JDK are: 1. Java Compiler, 2. JVM, 3. Java API.
That's not a good summary. There are certainly other things in a JDK apart from that.
As the JRE is the implementation of JVM
In fact the JRE includes an implementation of the JVM. And it also includes the core Java APIs, and a few other things.
As Holger points out, a JDK consists of a JRE plus some additional Java development tools. Or as he succinctly puts it:
"JDK = JRE + development tools"
So to answer your question:
does the Java API belong to JRE or JDK?
The Java APIs are included in both a JRE distribution or JDK distribution, but the phrase "belong to" doesn't have much meaning in this context.
(Now one could debate whether a JDK "contains" a JRE (or not), and whether the JRE "contains" the Java APIs. But to be honest it is a pointless debate. What really matters is that the Java APIs are present in both kinds of distribution.
Also, this is substantially moot in Java 11, since Oracle no longer provides JRE distributions for either Oracle or OpenJDK Java. It is now JDK only.)
A picture is worth a thousand words.
However, please note, the above diagram reflects the structure of JDK 8 and for later editions it is different.
I hope this is not off-topic for SO (I hesitated between SO and programmers.stackexchange) but as far as I can tell this is a "practical, answerable problem that is unique to the programming profession" so it's complying with the FAQ.
Which version of the JVM do you need in order to run which version of Clojure (Clojure on the JVM, this question is not about ClojureScript)?
The page here: http://clojure.org/getting_started states that:
Clojure requires only Java 1.5 or greater
But is this always going to be the case?
And what about the Clojure ecosystem, like Leiningen?
Basically I'd like to know if I can count on Clojure to be able to develop a desktop app that should run on systems, including OS X systems, that are never going to get Java 6 nor more recent versions of Java (for example on some OS X versions Apple stated that no JVM 6 would ever see the light).
I am not on the Clojure/core team, so I don't have inside information, but here is how I would approach this situation.
Take the latest version of Clojure (1.5 as of this writing) and test it against Java 1.5 for the things you need to do and any Clojure libraries you need to use and stick with that. If Clojure 1.5 is Java 1.5 compatable, it will always be so, since that release is immutable.
I would not make the assumption that all Clojure versions after 1.5 will be Java 1.5 compatible and you definitely can't assume that Clojure libraries will be. For example, I just released a Clojure library that requires Java 1.7 (since it uses a java.util.concurrent class introduced in Java 1.7).
Since Leiningen gives you maven-like dependency resolution if you test all your libraries and your chosen version of Clojure against Java 1.5 and they work, then you can stick with that set of versioned dependencies for as long as you want to keep the app running. Your only risk at that point is that some bug fix releases of a non core library might not be Java 1.5 compatible any longer. This risk is proportional to how many non-core Clojure libraries you need to use.
If you are selective about what libraries you use, then targeting Java 1.5 is certainly feasible.
Clojure is very conservative about it's Java version requirements - hence the dependency on version 1.5 only.
Many libraries depend only on Clojure itself, so will run quite happily on the 1.5 JVM
Some libraries require >1.5, these tend to be more advanced libraries that have requirements for interop with specific Java features (e.g. newer concurrency code).
Note: I personally write all my apps/libraries to target Java 1.6, since I think that is a reasonable minimum and the vast majority of Java-based systems are at 1.6 or above. I'm willing to live with the potential loss of a few users who are stuck on 1.5. Also, even if a future version of Clojure does abandon 1.5, I expect it will continue support for Java 1.6 for a long time.
Notably, in Clojure 1.6 they have bumped the version of Java to 1.6:
The Clojure 1.6 Release Notes
include this ticket:
CLJ-1268: Require Java 1.6 as minimum for Clojure
So, "no" is the answer to the original poster's question of "But is [Clojure requires only Java 1.5 or greater] always going to be the case?"
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.
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.