I've recently been messing around with an open-source Java web app. I'm using JDK 7 locally but I know that the upstream builds using JDK 6.
I want to write some code that uses classes that only exist in JDK 7 (currently, ThreadLocalRandom). I can do that on my local system just fine, but when I want to send patches upstream I have to hunt down any such references and translate them to the equivalent JDK6-safe code, which is a pain in the butt.
Is there a way to have both JDK6 and JDK7 source in the project, and have Eclipse automatically use the appropriate version at compile time based on the project target? I would like something that's easy for both myself and the upstream maintainer, so nothing like weird build scripts or text replacement.
The project does use Guice, if that helps, although I think doing it at runtime might be too late (because then the maintainer wouldn't be able to compile using JDK6 tools).
I'm only at "dabbler" level in Java, so please use small words.
Related
I am trying to use Emscripten's emconfigure and emmake to compile OpenJDK for the web. The end goal would be to be able to run uncompiled java code natively in the browser. However, running emconfigure ./configure throws the error
configure: The C compiler (located as /usr/lib/emscripten/emcc) does not seem to be the required gcc compiler.
configure: The result from running with --version was: ""
configure: error: A gcc compiler is required. Try setting --with-tools-dir.
I have been searching all day and I haven't found anything along the lines of this error. Is there any easy workaround for this? Should I even be trying to build OpenJDK this way?
Is there any easy workaround for this?
I doubt it. If you look at (for example) jdk11u/make/autoconf/toolchain.m4 you will see the toolchains that are supported on various platforms. Emscripten is not listed.
I expect that emconfigure is trying to use the JDK's autoconf-based configuration framework. And that framework is checking the compiler you are trying to use ... and saying Nope!
You may be able to modify the auto-conf macros to support the Emscripten tool chain. But the next problem will be getting the code to actually compile. And then to getting it to run.
Should I even be trying to build OpenJDK this way?
It is not up to us to say what you should do.
However, I would make some observations.
If you are expecting this to work without significant effort, you are sadly mistaken.
What you are doing is equivalent to trying to port Java to a new OP platform and hardware platform. This is is a massive project. In addition to just getting the JVM to compile, you also have the problem of getting the Hotspot JIT compiler to generate WebAssembly code.
This is probably a bad idea anyway. Once upon a time, mainstream web browser vendors did support Java in the browser. But there were so many "security issues" that (virtually) all vendors have dropped support. Oracle saw the writing on the wall, and in Java 9 they started the process of removing support from the OpenJDK codebase. Applet support and JNLP are gone, and they are planning to get rid of the SecurityManager framework.
What you would be doing is bring back Java support in the web browser ... with the security safeguards stripped out.
Basically, the Java SE platform is to rich to implement securely in a web browser.
If you are still keen on building a JVM using Emscripten, take a look at https://github.com/emscripten-core/emscripten/issues/3342.
But note that they are talking about building JamVM, which is Java 1.6, and hasn't been touched since 2014.
My team is using Pebble template engine for preparing messages. We have done lot of POC on this and everything looks good in our side. We decided to implement that.
Now problem we see here is we are having JRE1.6 in our application servers but pebble jars are compiled in JDK1.7. So we are facing version mismatch error. Can anyone suggest a workaround for this problem?
We are already approaching our release timeline and stuck here :(
Technically, there are 4 options:
You start searching; sometimes either the providers of libraries; or some "mirror site" somewhere has kept older JARs. Maybe those would work instead.
You upgrade your application server to run on a 1.7 runtime.
You could try to de-compile those JARs; to then compile them with Java 6.
Turn to the home page of peeble, find that it points to GitHub ... in other words: we are talking about open source here. So: you download the source, and you build your own jars; using a Java 6 environment.
Option 3 is obviously the most "hackish" one; and there might even be licence terms preventing you from doing that. And on the other hand, option 2 sounds scary; but you know: when you just change the underlying JRE (without touching your app server itself) there is a certain chance that this "just works".
And the real takeaway here: such subtle details are important. You should improve your processes to discover them early up; not during the last 5 minutes of your schedule.
I'm about to start setting up programmatic access to vTiger 5 from a Java application, and I was looking for a client library that will interface with the REST API. The vtwsclib library seems to be the right (only?) way to go. It looks like v1.0 was released in 2008 and over the course of a year, the version moved along to 1.4
There doesn't seem to have been any changes to the library since, except for a couple of weeks ago (2014-08-26) v1.5 was released. There's no documentation for it, either on the download page (like the other versions) or in the downloadable itself (that I can see).
So what's the deal with this new version? Is it suitable for working with vTiger 5? I'm considering migrating to vTiger 6. Is the the 1.5 library targeted at vTiger 6? Does it make no difference which version of the lib I use?
According to my findings, there are no significative changes in the .php, .js or .py code of version 1.5 compared to 1.4, and for the Java code it appears most changes are related to the project files and not the code itself.
I obtained the "diff" by extracting 1.4 to an empty git repository and subsequently adding 1.5 to it.
The repository is hosted at this link so you can examine by yourself.
Based on this, the answer to your question is that you can use it for Vtiger 5 as little or no changes seems to have been made. Please improve this answer if needed.
When I'm making a new JNLP file, I have to enter the versions of JAVA that my applet can work with, for example
<j2se version="1.6+">
Obviously, I want my applet to work with as many versions as it can, (I do, right?) how can I know what is the minimum required version to run my applet?
obviously, I want my applet to work with as many versions as it can, (I do, right?)
I disagree. It is well known that running Java in the web browser is a security nightmare. The best approach (for your users' security!) is to not use applets at all. But if you must do it, then you should be aiming to do it as securely as possible. That means writing your JNLP file to insist on a recent version of Java. Preferably, the most recent patch level of Java 7.
But to answer your Question, the simplest test to find the oldest a version of Java should support your application is to attempt to compile it with that version of the JDK. If it compiles on an old version JDK, then it is fairly likely that it will run.
But then you should test it, because successful compilation does not guarantee that the application will run properly.
And as #Lonzak points out, there is a separate issue of whether the user's installed Java supports JNLP.
There ought to be a better way but the following are the most general ones in my opinion:
Set the version of the Java Applet in your IDE to the lowest version you want to support and start programming.
Check the libraries/functions you need and check in which version they have been added.
When you want to use the JNLP mechanism you are bound to the next generation java plugin. It is supported starting with Java 1.6.0_10 (6u10). Java version older than that does not support JNLP. So if you want to support older Java versions you have to use the "old" mechanism (e.g. applet, object and embed tags).
So what would could you do?
Write a preceding applet, which is compiled with Java 1.4 (or even earlier). This applets basically only checks the Java version and other prerequisites. If the Java version is not sufficient (<6u10) it displays an error and otherwise the JNLP based applet is started...
I'm using eclipse to work on a project with portions written in Java, C, Perl, and bash. Which version of eclipse should I get for this? I'm currently using 3.5-CDT+perl-plugin and would really like better Java handling with out loosing the C. What plugin should i add for java?
How does Eclipse handle multi-language projects? when I hit "new project" what do I click?
can I add a new language to an existing project?
is there some other IDE that handles multi language projects?
Once you start adding plugins, the Eclipse that you start with doesn't matter. They just happen to provide commonly used sets of plugins prebundled - it's the same core Eclipse under the hood. Whenever I've worked with Eclipse, I've always started with Eclipse Classic and added the plugins that I want to use.
As far as multilanguage projects, I can't address that. I've never used Eclipse (or any other IDE) for multilanguage projects. I've used NetBeans with projects of different languages, but each project was of a particular language.
For perl, try using the Epic plugin. Update site: http://www.epic-ide.org/updates
The nice thing about eclipse is that whatever "version" you pick, you can add the updates from other versions (usually) without too many problems. Pick the version you use the most features of, then go back and add additional plugins as desired.
The best Eclipse is the one that installs the cleanest on your current OS setup. Most of the Eclipse issues I've had have had less to do with the language (the exception being PHP) and more to do with my underlying OS. That said, I haven't even had those issues in a couple of years.