jre comes with many libraries in rt.jar one of which is com.sun.istack.internal*. I needed the documentation of com.sun.istack.internal.Nullable(which I found being used by google in its CacheBuilder) and first I thought was to go to docs.oracle.com to find its documentation and there I found nothing about it. Next went to source folder sourced with jdk and I didn't find com name entity in the said folder. Next I take a look at the jre7 release and take a look at all the packages and class and found no mention of Nullable there. Though SO had one mention of it, but nothing concrete. I am still puzzled where to get its documentaion and src if needed. I even looked legacy sun api documentation at oracle but nothing mentioned about it. where does oracle document there policy about ported packages and their being standard or not-standard.They must have documented it somewhere it is just that I'm taking too much of time to get there.
Please point me there.
EDIT: Actually the javax.annotation.Nullable is being used in google CacheBuilder and not com.sun.istack.internal.Nullable.
Also for someone who may face this issue: javax.annotation.Nullable is not part of Java SE as of now, and it is being ported in jsr305 jar. So if you are planning to use CacheBuilder or just going through its code, do add jsr305 jar in your class path, else eclipse get confuse and will point you to com.sun.istack.intenal.Nullable when ever you hover your cursor over Nullable.
Guava doesn't use com.sun.istack.internal.Nullable. Everything that is not documented in the official Java SE javadoc is internal code, and should not be used in applications.
You're probably looking for javax.annotation.Nullable, which is part of JSR305.
Here is a link to the source code:
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/com/sun/istack/internal/Nullable.java/
(This link may break in the future, but you should be able to find an equivalent using a Google search.)
The reason that you can't find the source code or javadocs in the standard JDK / JRE distributions is that this is a INTERNAL class. There is a long-standing Oracle / Sun policy of discouraging developers from writing code that is dependent on Java internal classes.
FWIW - this is just an annotation, and the meaning is pretty much what the class name implies.
UPDATE - Apparently, the real cause of this confusion is that you didn't include the JSR305 jar in your buildpath. It is a dependency for CacheBuilder. Eclipse classname completion is then doing its best ... but failing.
It is said that It's Oracle's intent that these classes be inaccessible at compile-time.
Below is my workaround in case adding a modern jar for those annotation is not allowed.
If using Gradle, add:
compileJava.options.compilerArgs << "-XDignore.symbol.file"
If using Ant, change the javac tag like:
<javac srcdir="src" destdir="${classes.dir}" classpathref="classpath" memoryinitialsize="512m" memorymaximumsize="1024m" fork="true">
<compilerarg line="-encoding utf-8 -XDignore.symbol.file"/>
<exclude name="test/**"/>
</javac>
Related
While setting up a project as a template for Slick2d based projects following the instructions here:Slick2d wiki using the provided code for testing setup here at run-time I keep getting a giant block of sealing errors. My thought is that this problem stems from the version of ljgwl.jar in both libraries, however Slick requires both in order to function properly. How can I resolve this?
Package sealing is a Java feature implemented in part in the JAR file format. It is discussed in several places, including in Oracle's Java Tutorial, but the bottom line is that when package sealing is enabled in a Jar's manifest, no classes belonging to that package can appear in any other JAR file.
My thought is that this problem stems from the version of ljgwl.jar in both libraries, however Slick requires both in order to function properly.
I'm not sure what you mean by "library", as that is not a Java concept. I suspect, however, that you're trying to say that you somehow have ljgwl.jar files from two separate sources, and you've put both into your project classpath. That would indeed be a problem, and more than just for package sealing. You can, in fact, be thankful for the sealing errors, for they may have saved you from subtler, more difficult to diagnose runtime errors.
How can I resolve this?
You should have only one copy of LWJGL in your classpath, regardless of any requirements enforced by package sealing, and regardless of how the classes are packaged in jar files. It looks like the Slick2D distribution may come with a copy of LWJGL -- in that case, it's probably wisest to use that one. As long as it's in your classpath (as it must be anyway for Slick2D to use it), any class anywhere in your application can use it.
It gets tricky if you need to contend with a inconsistent requirements for LWJGL version, or if you have obtained a JAR that incorporates the LWJGL classes along with something else, but that doesn't change the bottom line: you must choose one version of LWJGL, use that version exclusively within your application, and include only one copy of it in your classpath.
Question:
Do you know of a tool that will work without too much compatability issues that can do markup on Java Source Code and keep most of the integrity of the program intact, or do you know how to make JavaML/JavaML 2.0 work?
The tool should ideally be able to either process many projects or be scripted into working over many projects.
Explanation:
I am trying to do research on a huge set of Java Source Code (About 20.000 Projects). In essence for my research to give any sort of results I need to be able to identify comments and different parts of code in the source code, for example I need to be able to differentiate between function declaration, function call, variable declaration, variable usage, if-blocks and so forth. - At its core: What JavaML (Java Markup Language) does.
Example:
import java.applet.*; // do not forget this import statement!
import java.awt.*; // Or this one for the graphics!
public class FirstApplet extends Applet {
// this method displays the applet.
// the Graphics class is how you do all the drawing in Java
public void paint(Graphics g) {
g.drawString("FirstApplet", 25, 50);
}
}
Becomes:
<java-source-program>
<java-class-file name="FirstApplet.java">
<import module="java.applet.*"/>
<import module="java.awt.*"/>
<class name="FirstApplet" visibility="public" line="5" col="0" end-line="11" end-col="0" comment="// do not forget this import statement!// Or this one for the graphics!">
<superclass name="Applet"/>
<method name="paint" visibility="public" id="FirstApplet:mth-15" line="8" col="2" end-line="10" end-col="2" comment="// this method displays the applet.// the Graphics class is how you do all the drawing in Java">
<type name="void" primitive="true"/>
<formal-arguments>
<formal-argument name="g" id="FirstApplet:frm-13">
<type name="Graphics"/>
</formal-argument>
</formal-arguments>
<block line="8" col="32" end-line="10" end-col="2" comment="// do not forget this import statement!// Or this one for the graphics!// this method displays the applet.// the Graphics class is how you do all the drawing in Java">
<send message="drawString">
<target>
<var-ref name="g" idref="FirstApplet:frm-13"/>
</target>
<arguments>
<literal-string value="FirstApplet"/>
<literal-number kind="integer" value="25"/>
<literal-number kind="integer" value="50"/>
</arguments>
</send>
</block>
</method>
</class>
</java-class-file>
</java-source-program>
But here comes the problem. I have been trying to make JavaML and JavaML 2.0 work. But there is some quite clear compatibility problems. I have for JavaML tried running virtual machines of old and new ubuntu implementations (10.04, 12.04 and 14.04) in an attempt to compile the source code as instructed by JavaML's website, for all versions I keep getting errors while configuring, there seems to be issues with the version of Jikes used in JavaML that triggers issues with the g++ compiler. - Using newer versions of Jikes renders the patch from JavaML worthless, and thereby makes compilation of JavaML impossible.
For JavaML 2.0 it comes with an .exe file that can be run on windows. You just have to set it up with the correct path to your Java install (see below for instructions). However this also gives me problems. Using the newest Java (1.8.0_40) it will tell me: 'chaos: CODE "15" is an invalid tag !!!'
When I set it up with Java versions: 1.5.0_14 , 1.5.0_12 , 1.5.0 , 1.4.2_19 and 1.3.1_28 the .exe file will crash, but first produce a .tok file and an empty .xml file.
Instructions for JavaML 2.0
Download the JavaML 2.0 project
Extract to somewhere
Start your cmd (Command prompt)
Navigate to the folder you placed your JavaML 2.0 project in
Find your Java implementaiton (Typically stored at: C:\Program Files (x86)\Java)
Find your rt.jar file (Typically stored at: C:\Program Files (x86)\Java\jre1.8.0_40\lib\rt.jar)
Write the following lines in your cmd
s*
set CLASSPATH=.;C:\Program Files (x86)\Java\jre1.8.0_40\lib\rt.jar
jikes +B +L +c +T=3 +ulx FirstTest.java
If anyone still is looking this problem up I wanted to make sure there was some sort of answer.
In my research I couldn't find a tool that acted as JavaML and I couldn't make JavaML work on any newer system. Instead I created my own tool in Java, which have given me quite some headaches, and it is most certainly not worth publishing. Creating such a tool by hand took me about 30 man-hours.
If you really need a tool that acts like JavaML I suggest that you customize a parser, as also suggested by immibis.
I was told by a friend to take a look at the OpenJDK compiler, and customize it. There is a guide to customization of the compiler found here.
- This is however a task for people that understand language, syntax and compilers at a deep level.
Good luck.
Use JavaCC to create a custom parser. They already have example of analyzing Java code.
I have class file. It is a result of compilation. Can I know the compiler version which was used for creation of this file?
As a result I want to know something like java 1.6.0_45
No. Class file contains only format version which is not directly corresponds to compiler version.
PS: Class files mainly can be found inside jars. Jars often contains manifests. Manifest may contain compiler version.
PPS: See also here
Yes, that information is part of class file. More information here.
Edit:
I stand corrected. The compiler version is not part of the class file. I confused major and minor versions with compiler version. Still keeping the link since it provides useful information pertaining to the question.
Has someone tried to use MessagePack with an Android app?
Is it possible? I have tried to use the Jar from msgpack-java and received the following Exception:
Caused by: java.lang.ExceptionInInitializerError
at org.msgpack.Packer.pack(Packer.java:532)
at org.msgpack.MessagePack.pack(MessagePack.java:31)
... 15 more
Caused by: java.lang.ExceptionInInitializerError
at org.msgpack.template.TemplateRegistry.<clinit>(TemplateRegistry.java:38)
... 17 more
Caused by: java.lang.VerifyError: org.msgpack.template.BeansFieldEntryReader
at org.msgpack.template.builder.BeansTemplateBuilder.<init (BeansTemplateBuilder.java:42)
at org.msgpack.template.builder.BuilderSelectorRegistry.initForJava(BuilderSelectorRegistry.java:73)
at org.msgpack.template.builder.BuilderSelectorRegistry.<clinit>(BuilderSelectorRegistry.java:38)
... 18 more
The code that I use is very simple
PrintWriter out = new PrintWriter(socket.getOutputStream());
Message msg = new Message();
msg.body = "asdasdasd";
msg.from = "qwe";
msg.to = "ttt";
byte[] bytes = MessagePack.pack(msg);
out.print(bytes);
out.flush();
I have javassist.jar, msgpack-0.5.2.jar, slf4j-api-1.6.2.jar and slf4j-jdk14-1.6.2.jar in my lib directory.
In my server application this code works fine with the same libraries.
(Hopefully) FINAL UPDATE
msgpack : 0.6.8 works on Android without any problems
msgpack-rpc : 0.7.0 works on Android with one caveat.
Specifically, you need to add the following to onCreate for API Level 8 (Android 2.2.1), and possibly lower:
java.lang.System.setProperty("java.net.preferIPv4Stack", "true");
java.lang.System.setProperty("java.net.preferIPv6Addresses", "false");
due to this bug.
If you want to see a simple example, here's a pair of projects set up for this purpose:
https://github.com/mikkoz/msgpack-android-test-server/tree/master/msgpack-android-test-server
https://github.com/mikkoz/msgpack-android-test-client/tree/master/msgpack-android-test-client
Previous Versions
UPDATE: as of 0.6.7 msgpack should be compatible with Android (there is a small dependency exclusion issue). Check the text below for msgpack-rpc (which also might be adapted in the future).
NOTE: If you're also using msgpack-rpc, you need to do the following steps:
Download the msgpack-rpc source from git://github.com/msgpack/msgpack-rpc.git (specifically, the "java" folder).
Change the main msgpack artifact version to the one you've built.
In org.msgpack.rpc.loop.netty.NettyEventLoop, change the NioClientSocketChannelFactory to OioClientSocketChannelFactory(getWorkerExecutor()).
Build the MessagePack-RPC in the same way as in the case of the main MessagePack JAR (see Step 11 above).
The NettyEventLoop replacement is due to this issue:
http://markmail.org/message/ypa3nrr64kzsyfsa .
Important: I've only tested synchronous communication. Asynchronous might not work.
And here's the reason for msgpack not working with Android prior to 0.6.7:
The reason for the error is that MessagePack uses several java.beans classes that are not included in the Android SDK. You're probably using the MessagePackBeans annotation.
This is a similar problem to the one described here, for which the general solution is outlined here. Unfortunately, in our case it requires a rebuild of msgpack. Here's what I did (you can almost certainly skip Steps 5 and 8, but I haven't tried it that way) :
Download the MessagePack source from https://github.com/msgpack/msgpack-java.git.
Import the MessagePack source as a project in your IDE.
Download the Apache Harmony source for the relevant packages from http://svn.apache.org/repos/asf/harmony/enhanced/java/trunk/classlib/modules/beans/src/main/java .
Copy these packages into your MessagePack project's src/main/java folder:
java.beans
java.beans.beancontext
org.apache.harmony.beans
org.apache.harmony.beans.internal.nls
In your MessagePack project, remove the following classes:
PropertyChangeListener
IndexedPropertyChangeEvent
PropertyChangeEvent
PropertyChangeListenerProxy
PropertyChangeSupport
Rename the java.beans packages to something different, e.g. custom.beans .
Change all java.beans references to the renamed ID, so again e.g. custom.beans. This applies especially to BeansFieldEntryReader (this class is the reason for the original error).
Change the custom.beans references for the five classes you removed in Step 5 back to java.beans.
In the org.apache.harmony.beans.internal.nls.Messages class, comment out the method setLocale, and remove the imports associated with it.
Remove all classes that still have errors, except Encoder. In that class, comment out all references to the classes you've removed. You should now have an error-free project.
Build the MessagePack JAR:
If you're using Maven, change the version in the pom.xml to something unique, run Maven build with the install goal, then add the dependency in your Android project with that version.
If you're not using Maven, you have to run the jar goal for Ant with the included build.xml. Replace the msgpack JAR in your Android project with this one.
If you're publishing your app, remember to include the relevant legal notice for Apache Harmony. It's an Apache License, just like MessagePack.
That should do it. Using your example code, and my own data class, I was successfully able to pack and unpack data.
The entire renaming ritual is due to the fact that the DEX compiler complains about java.* package naming.
There is a critical msgpack bug saying data packed with msgpack will get corrupted on the Dalvik VM. http://jira.msgpack.org/browse/MSGPACK-51
There is an ongoing effort by #TheTerribleSwiftTomato and the MessagePack core team to get MessagePack working on Android, please see the related GitHub issue. The fix mentioned in #TheTerribleSwiftTomato's answer is to be found here.
Update
I've managed to get it at least running on Android by (painstakingly) adding all the necessary javassist Classes which are currently required for the build to succeed. An extra 600KB gain in size, yet at least it seems to work. All in all, it appears to be working to some extent on Android, eventually check out the lesser-known resources about Message Pack such as its User Group and its Wiki for more information.
On a side-note, be sure to use a HTTP Request Library (such as LoopJ's Android Async HTTP or Apache's HttpClient) which can handle binary data.
Last but not least you can ping me if there is interest in this jar which makes MessagePack seemingly work on Android – credits go out of course to #TheTerribleSwiftTomato who supplied the fix above!
I suggest you write this in the main proguard-rules file-
-dontwarn org.msgpack.**
-keep class org.msgpack.** { *; }
I am looking for a replacement for javadeps, which I used to use to generate sections of a Makefile to specify which classes depended on which source files.
Unfortunately javadeps itself has not been updated in a while, and cannot parse generic types or static imports.
The closest thing I've found so far is Dependency Finder. It almost does what I need but does not match non-public classes to their source files (as the source filename does not match the class name.) My current project has an interface whose only client is an inner class of a package-private class, so this is a significant problem.
Alternatively if you are not aware of a tool that does this, how do you do incremental compilation in large Java projects using command-line tools? Do you compile a whole package at a time instead?
Notes:
javadeps is not to be confused with jdepend, which is for a very different purpose.
This question is a rewrite of "Tool to infer dependencies for a java project" which seemed to be misunderstood by 2 out of 3 responders.
I use the <depend> task in ant, which is ok, but not 100% trustworthy. Supposedly JavaMake can do this dependency analysis, but it seems to be rarely updated and the download page is only sometimes available.