I am trying to compile my application with java 9 and it is failing because
native2ascii executable is not there. Has it been removed in Java 9? Is there another tool that does the same thing?
Yes, native2ascii was removed in Java 9. From the bug report to remove it, "JEP 226 proposes to support UTF Properties file that will address the original motivation of creating the native2ascii tool." For more information visit JEP 226.
Related
I am using same command to generate javadoc with jdk 1.8 and 1.9 while doc gets generated with errors and warning in jdk 1.8 but is not getting generated with 1.9.
Below is the command I am using:-
C:\Program Files\Java\jdk1.8.0_05\bin>javadoc -d D:\APIdoc -sourcepath D:\MyFile\src\main\java -subpackages com.abc.dap.pqr
Output:
100 errors
100 warnings
Doc generated successfully
C:\Program Files\Java\jdk-9\bin>javadoc -d D:\APIdoc1 -sourcepath D:\MyFile\src\main\java -subpackages com.abc.dap.pqr
Output:
100 errors
Doc not generated
Below are the errors:-
error: package [package_name] does not exist
error: cannot find symbol
Same errors are observed in jdk1.8 and 1.9 but I am unable to understand why doc is not generated with 1.9.
Please suggest workaround for generating javadoc with jdk1.9
It is a deliberate change in JDK 9 to treat the errors as unrecoverable and exit without generating the javadoc. This is documented in the JDK 9 release notes (http://jdk.java.net/9/release-notes#JDK-8175219).
As noted in the comments then the using the old doclet (with -Xold) might work for this case but it doesn't support module information. Also the old doclet will be removed in the next release.
You may have better luck by turning off some of the checks using -Xdoclint:-<group>, particularly -Xdoclint:-reference which will cause it to ignore issues relating to the references to Java API elements from Javadoc tags, or even -Xdoclint:none to turn off all checks. If that doesn't help, you can invoke the legacy javadoc tool with -Xold.
See javadoc -X or the javadoc documentation for more information.
I'm compiling a JNI library with Gradle. It clearly knows how to find a JDK (as the Java half of the project compiles perfectly). However, I'd need a path to the JNI header files in a Gradle native (C++) project.
Is there a way to obtain the path of the JDK being used from a Gradle build file?
According to the top reply here, you can get currently running Java path from the property java.home. In Gradle:
println System.getProperty('java.home')
or more Groovy:
println System.properties.'java.home'
Since this is the top answer on Google:
Jvm.current().getJavaHome()
Note that the JVM class is internal as of Gradle 6, use it at your own risk.
I have Java 7 running on my mac:
System.out.println(System.getProperty("java.version")); // prints 1.7.0_05
Project was created using
Project properties confirm, i am on Java 7
Default system Java is 7
The following however results in syntax error
public static void main(String[] args) {
// Underscores in Numeric Litarals are ok here
int i = 11_234;
}
Eclipse is complaining with Syntax error on token "_234", delete this token
On Eclipse's Project|Properties dialog, there two entities Java Build Path and Java Compiler. The former will tell you what classes are used during the build, and you may have a Java 7 JRE listed there. The latter, however, is the compiler that will be used to compile your code. It is possible to have Eclipse use a Java 6 compiler even with a Java 7 JRE on the build path.
My guess is that you are using Helios, not Indigo. See Programming Java 7 in Eclipse
Make sure your version of Eclipse is 3.7.1 (this is Eclipse 3.7 Maintenance Build) or higher (see JDT/Eclipse Java 7 Support) and that you have registered Java 7 with Eclipse (see Eclipse and Java 7).
I'm trying to deploy a JSP-page on Jetty, using the Jetty WTP plugin for Eclipse. But I get the error below. It looks like Jetty can't find javac. Is there any settings I have to do for the Jetty WTP plugin in Eclipse or how do I fix this?
The JSP page works fine if I export my project as a .war-file to jetty\webapps and then start Jetty manually using java -jar start.jar. But it doesn't work if I deploy using the Jetty WTP plugin for Eclipse as described.
I have my JAVA_HOME set to C:\Program Files (x86)\Java\jdk1.7.0_01 and I use Jetty 8.0.4 on Windows 7.
Servlets is working fine with the current setup. Any suggestions on how to solve this for JSP pages?
HTTP ERROR 500
Problem accessing /MyJavaWeb/formProcess. Reason:
PWC6345: There is an error in invoking javac. A full JDK (not just JRE) is required
Caused by:
org.apache.jasper.JasperException: PWC6345: There is an error in invoking javac. A full JDK (not just JRE) is required
at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:92)
at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:378)
at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:119)
at org.apache.jasper.compiler.Jsr199JavaCompiler.compile(Jsr199JavaCompiler.java:208)
at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:384)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:453)
at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:625)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:374)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:492)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:378)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:558)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:488)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:520)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:973)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:417)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:907)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:271)
at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:98)
at com.example.FormProcessServlet.doPost(FormProcessServlet.java:39)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:755)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:558)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:488)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:483)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:973)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:417)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:907)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
at org.eclipse.jetty.server.Server.handle(Server.java:346)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:442)
at org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:941)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:801)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:224)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
at java.lang.Thread.run(Unknown Source)
As Jan Bartel suggested, from Jetty: How to configure JSP:
by adding the line below in the start.ini-file in Eclipse, it works fine.
-Dorg.apache.jasper.compiler.disablejsr199=true
I too happened to suddenly get the org.apache.jasper.JasperException: PWC6345 with my Eclipse installation and the Jetty Maven Plugin (which I use to start up Jetty from within Eclipse).
The reason was that I updated my JDK installation shortly before. Inside Eclipse, this caused to change the "Installed JRE" to point to a plain JRE installation instead of a full-fledged JDK installation. A JDK installation is needed for Jasper, as Jasper needs javac (which is not provided by JRE).
In my case, the solution was to provide Eclipse with the JDK installation. To do so, select Window -> Preferences -> Java -> Installed JREs. Here, click Add..., then point to your JDK installation (in my case, JRE home should point to C:\Program Files (x86)\Java\jdk1.7.0_17). Click Finish. Then back in the Installed JREs overview, remove the old JRE reference and select the newly added JDK installation.
I got the PWC6345 error when running a webapp with Run-Jetty-Run plugin.
The fix was to change the Execution environments settings in Preferences.
Since I'm using java 7 I needed to change the setting for JavaSE-1.7.
Probably other execution environments will behave similarly.
Window -> Preferences -> Java -> Installed JREs -> Execution environments
Select JavaSE-1.7 on the left -> pick the *jdk*1.7.x_xx on the right hand side
Ok, solved this after a lot of searching around.
Download any jdk and point JAVA_HOME to this jdk.
Inside this jdk folder you will find ./bin and ./jre/bin
Copy the javac from ./bin and paste it in ./jre/bin [remember copy not cut]
Now in eclipse, Run->External-Tools->External-Tools-Configurations, select the build.xml for of your project in the left pane and click on the JRE tab in the right pane.
Click on installed JREs and add the jdk in the previous step.
Once done, select this new JRE (jdk1.6.0_31) as the 'Separate JRE', click on apply at the bottom and run.
This assumes you are doing a jetty:run using ant on eclipse.
Strange because this thread suggests:
The solution was to install the package jdk7-openjdk.
Perhaps this should be added to the list of dependencies (or maybe for jetty, and not solr itself)?
But that doesn't help much on Windows, where the binary for openjdk7 aren't easily available.
(In "OpenJDK availability for Windows OS" comments, eckes mentions having found some openjdk binaries for Windows, as part of the Build b146. However, said releases aren't maintained any more)
The bug report filled by the OP Jonas is closed with a simple reference to the Eclipse wiki page "Jetty/Howto/Configure JSP".
You have planty solutions guys but I thought that it exist a solution better than fix the start.ini
I lived the same problem and then I realize that it may be because I did have a JDK7 for 64bit while I should have a JDK7 for 32.
So I fixed my problem by downloading and use the JDK7 for 32Bit.
Also, you would still need to
Use the JDK and not the JRE
Set your JAVA_HOME
I am running on Windows by the way ...
I have the same problem. When I run where java, the output is:
C:\Windows\System32\java.exe
D:\Program Files\Java\jdk1.7.0_25\bin\java.exe
Of course the first one is incorrect. So my problem lies in the PATH. I can rectify this by either removing the java.exe in the directory C:\Windows\System32\ because I'm sure it's useless, or putting the second entry in front of the first one.
So When encountering this problem, please check your PATH for the jdk. I hope that my problem and my solution is helpful in some way.
I got the PWC6345 error when running jetty-runner 9.2.1 standalone from Windows 7 cmd (or batch file) with Oracle JDK 1.7.0_60, and none of the other suggestions in this or other forums worked. I'll leave my workaround here, in case it helps someone...
After installing the JDK, running 'where java' showed two different java.exe paths, the first being in the Windows system folder, and the second in the JDK folder (which is the one I added to the path manually). Both of these are actually installed by the same JDK installer. The java.exe in the system folder was taking precedence and causing the full JDK to go undetected.
Placing the JDK bin folder (e.g. "C:\Program Files\java\jdk1.7.0_60\bin") on the path before the other system paths fixed the issue.
In addition to updating the JAVA_HOME (see above)...
If you're encountering this error from command line (e.g. starting Jetty server from dos window), check where windows is finding the java.exe:
where java
If windows comes back with a path showing to your jre, then check your PATH. Chances are the %PATH% contains a path pointing to the jre instead of jdk.
if you set environment variable JRE_HOME , please unset or delete it
and start server again .
In liferay 7 : I got this error fixed by changing the runtime environment of the server from jre to jre with jdk
I got this error when deploy war package to our server.
My deploy command is (applied web container you may find):
java -jar jetty-runner.jar --port 8020 xx.war
I write this answer because it confused me almost one day. I tried some methods above but failed.
Finally I found there is only jre on my servers but not full jdk.
$ls /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.131-2.b11.el7_3.x86_64
jre
I fix it with searching available jdk and install one.
$yum search java | grep 'java-'
$sudo yum install java-1.8.0-openjdk-devel.x86_64
(Notice the -devel)
I added this line to 'eclipse.ini' file which is present inside eclipse folder.
-vm
C:\Program Files\Java\jdk1.8.0_131\bin\javaw.exe
and I also change the JRE path in eclipse
windows -> preferences -> java -> Installed JREs
and provided path upto jdk
C:\Program Files\Java\jdk1.8.0_131
I spent good amount of time on this issue, but it turned out to be very simple. All you have to do is:
choose the JDK instead of JRE while configuring the server runtime!
It worked like a champ, I had this issue with glassFish 4.0
My work project needs to be compiled and run under JDK1.5 and I'm on a Mac. I followed the instructions here to get 1.5 back on Snow Leopard, and it works fine when building from IntelliJ IDEA, or if I'm just in the same directory as the build.xml and try "ant CleanRebuild" When I "Run Target" in NetBeans they're all compiled with the wrong version resulting in
java.lang.UnsupportedClassVersionError:
Bad version number in .class file
(unable to load class...
when tomcat is trying to start up.
So things I've tried
Set the "Java Platform" to 1.5 under the project properties/libraries.
Set the Source/Binary Format to JDK 5 under project properties/sources.
Pointed the ant home to the ant I'm using under preferences/ant
Renaming every javac executable I could find in the hopes NetBeans would fail to compile and I could figure out which one it was using (no luck)
Setting 1.5 as the default, resulting in the need to point $netbeans_jdkhome to the 1.6 jdk in order for NetBeans to even start.
All unsuccessful....
Again, if I cd into the directory of the netbeans project with the build.xml and run the command manually all is well....so NetBeans. What's the deal?
Revised answer
Assumptions: NetBeans version 6.9.1 (although likely applicable to most or all 6.x versions), alternative build systems (e.g., Maven) are not used...the default (Ant) is used.
NetBeans, by default, uses Ant as its build system for doing things like compiling a project, building a project, cleaning built files from a project, etc. Ant has two concepts that are applicable here: targets and tasks. A target, in Ant's vocabulary, is simply a "command" or a series of jobs that need to be completed for a particular job. In NetBeans, common targets are "Compile", "Build", "Clean and Build", etc. The "jobs" that a target completes are (among other things) Ant tasks. In NetBeans one task (which is particularly relevant in answering this question) is the Javac Task. This is the task that Ant uses to compile .java files into .class files.
An Ant-based project, and therefore a NetBeans project, uses the file build.xml to control the build process and tell Ant how to go about accomplishing the targets. In a NetBeans project, the build.xml is found in the root directory of the project, by default. NetBeans, however, uses a user-extensible build.xml file. The core targets and tasks defined by NetBeans are actually located in nbprojects/build-impl.xml and imported into build.xml within the first few lines of the file. The theory is that users can add or override things in build.xml while the core NetBeans-defined configuration remains untouched in the build-impl.xml file.
If you look in the default nbproject/build-impl.xml file for a NetBeans Java project, you will find the Javac task referred to twice. (Search for "<javac".) Both are in macro definitions, and therefore deep within the complexities of NetBean's default build configuration. If we refer to the Javac Task documentation we find that the tasks uses the compiler in the location specified either by the global build.compiler property, by the compiler attribute specified with the <javac... /> task, or the default which is the Java compiler that is used when running and, and thus the one that is used when running NetBeans (because it is what fires off the Ant process). Since we don't see build.compiler or the compiler attribute anywhere (in the default build-impl.xml), then we can only conclude that the default is being used.
So here we have the (more-or-less correct) first answer. NetBeans compiles using the JDK that was used to execute NetBeans by default. It looks like it is actually a bit more complicated than that simple answer, but it is essentially correct. If you look at the documentation for the Javac Task it alludes to "a class that implements the CompilerAdapter interface", which suggests that rather than calling the javac executable directly, Ant (and therefore NetBeans) compiles using the compiler class (that, in all likelihood, the javac executable also uses). Refer to the Original answer below to determine which JDK what used to run NetBeans.
So, what if you don't want to use the default JDK that was used to run NetBeans? This is where "Java Platforms" comes in. Go to the Tools menu, and click on "Java Platforms". You likely only have one platform defined here. (As an aside, this is actually the most correct answer to what JDK is used by default... the one defined here in the Java Platform Manager.) If you would like to compile against another Java version (say your default JDK is 1.6, but you want to compile against 1.5) then you would install the alternate JDK somewhere on your system, and then configure a platform here in NetBeans' Java Platform Manager. (I'll leave it as an exercise for you to find the documentation on how to add a Java Platform. A superficial search of the wiki didn't turn up anything obvious. In any case, it's fairly self-explanatory.)
Once a new platform is created in the manager, you would right-click on your project in the Projects tab, click on "Properties", and then on "Libraries". At the top, you would select the appropriate Java platform for the project. As soon as you change this value and click on "OK", NetBeans makes several adjustments to your build-impl.xml file that point it to the new JDK against which to compile. (It is instructive for the truly geeky amongst us to make a copy of the nbproject directory before making this change and to diff that against the new contents of the nbproject directory after the change is made.) The changes instruct the Javac Ant Task to use the (equivalent of the) javac executable of the specified platform. So here we have the most correct answer: NetBeans uses the equivalent of the javac executable (as invoked by the Ant javac task) that is specified in the project's Java Platform located under the Libraries node of the project's properties.
Original answer
The path to the JDK used by NetBeans can be found in the netbeans.conf file. Look for the netbeans_jdkhome entry.
You can also specify the jdkhome at runtime (*NIX example given):
netbeans --jdkhome /usr/bin/jdk1.6.0_22
The netbeans.conf file is found in different places depending on what OS you are using. See the NetBeans.conf FAQ on the NetBeans wiki for help finding the file.
A few additional comments...
...You can specify the -target option in the project properties. In NetBeans 6.9 right-click on the project, and choose Properties. Click on the Compiling node. Add your -target to Additional Compiler Options.
...I have read in a few places that specifying a target is not a guarantee that the code will run on a JRE whose version is lower than the JDK that built it. In other words, the recommendation seems to be that if you want 1.5 binaries, then compile with the 1.5 JDK.