I want to compile jdk itself. I mean, I want to modify String.class in jdk to see created string objects in the system. Is there any way to modify classes in the jdk? When I try to modify source by modifying rt.jar, I got the error.
java.lang.NullPointerException
at java.util.Hashtable.put(Hashtable.java:394)
at java.lang.System.initProperties(Native Method)
at java.lang.System.initializeSystemClass(Unknown Source)
Probably there is a signature problem.
That doesn't look like a signature problem. It looks like you changed something that's causing Hashtable to dereference a null pointer. Review the change you made and see why it's doing this. Recall that Java keeps internal references to String constants in some conditions. I'm guessing you broke one of those.
Is there any way to modify classes in the jdk?
Well, you can download, modify and build the OpenJDK releases of Java 6 from source. There's information on how to do this on the OpenJDK site.
But beware that changes to low-level Java classes (such as String) can have effects that are hard to a non-expert to understand. And the consequence could well be a JVM that fails in a way that makes println or printStackTrace() inoperative.
There is maybe another way: you download java.lang.String original source, doing your modifications and compile only this class.
When you start your main programm be aware when loading classes: first load your String class then the java runtime classes. Refer to the java manual and the -Xbootclasspath/p options to do it in the proper order.
When installing a JDK you may choose to install the sources as well. Do so. Or download the sources separately. Then
expand the src.zip and get the String.java file.
create a new project containing the String.java in package java/lang.
change it accordingly to your needs.
just compile it.
put the class into the bootclass path of your JDK. See More infos on Bootclassbath.
run your app.
java -Xbootclasspath/p:<changed String classpath> -cp <regular classpath> <your application main class>
But changing the JDK might not be a good idea and you are not allowed to ship a changed JDK (at least up to 1.6) due license restrictions.
And yes, your problem is most likely somewhere else. Remember select isn't broken ;-)
Related
I have tried the download folder for kotlininc, and did everything the instructions said. And I'm still getting an error saying:
error: Could not find or load main class org.jetbrains.kotlin.runner.Main
Is there a lite weight simple kotlin compiler for windows which is easy to install?
something like javac
or g++
etc
If you don't want an IDE, I would recommend using a build tool. Kotlin supports Ant, Maven, and Gradle.
Of course, using the plain kotlinc command-line compiler is the simplest, but you already linked to it. If you need help figuring out what you're doing wrong with that, create a new question and explain/show what you've tried.
I am a newbie to Java. I was trying to upgrade to jdk 1.8 and found the following errors on doing a "gradle test":
/u01/sv/home/sv900t1/sv_test/Test_Suites/SeleniumLibraries/src/main/java/com/csgi/svtest/selenium/CustomWriter.java:57: error: cannot find symbol
h2("Class "+classDoc.toString());
^
symbol: method h2(String)
location: class CustomWriter
/u01/sv/home/sv900t1/sv_test/Test_Suites/SeleniumLibraries/src/main/java/com/csgi/svtest/selenium/CustomWriter.java:58: error: cannot find symbol
printHyperLink(classDoc.toString()+".html","","Class description<br>",true);
^
symbol: method printHyperLink(String,String,String,boolean)
location: class CustomWriter
I referred to http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java/
and http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7u40-b43/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java/
(our code imports this: import com.sun.tools.doclets.formats.html.SubWriterHolderWriter;)
and found that many apis like h2(), printHyperLink(), hr(), table(), tableHeaderStart(), tableHeaderEnd(), tableEnd(), pre(), strong(), preEnd(), ul(), print(), li(), ulEnd(), printHtmlHeader(), center(), today(), printTop(), navLinks(), printBottom() and printBodyHtmlEnd() have been removed.
Is there a quick workaround that can enable us to bypass the symbol errors?
Or should we replace the missing apis with existing ones. This looks like a lot of work to me - being an entrant. Are there any existing examples on how to do that? I have searched the internet a lot, but could not find anything useful.
The code in CustomWriter.java is for outputting a Javadoc page using custom System Test tags. Any help is appreciated - we are short on time.
Well here's the problem. The classes in the com.sun.tools.* packages should be treated as internal APIs. There are clear warnings in the Java documentation that say that you should not write code that against these APIs.
For example:
Why Developers Should Not Write Programs That Call 'sun' Packages
Closing the closed APIs
In Java 8, the header of the class that your code is trying to use says:
This is NOT part of any supported API. If you write code that depends on this, you do so at your own risk. This code and its internal interfaces are subject to change or deletion without notice.
(The bolding is in the original!)
It didn't say that in Java 7 (ouch!) Indeed there are versions of the Javadoc FAQ which seem to encourage people reuse the standard doclet classes. Unfortunately, Oracle have decided to close off these classes, and have also made some breaking API changes which reinforces this, whether or not that was the intention of the changes
What can you do about it? Unfortunately, there is no easy solution:
Maybe you could find an truly open source Doclet codebase that you could modify.
Maybe you could find a commercial vendor or consultant who will do the work for you.
Or maybe you just "suck it up" and rewrite your code to work with the latest version of the (internal) APIs. And live with the possibility that you may need to take more pain in the future.
Or ... you could reinstall Java 7 on your build / test boxes and use it (just) for running your custom doclets.
UPDATE - It has been pointed out that the "rule" above is for sun.* packages. However:
The document doesn't say anything about com.sun.* packages, so it is not valid to infer that they fall into the same category as java.*, javax.* and others that are explicitly stated to be reserved for Java supported APIs.
There are other examples of com.sun.* packages that are explicitly stated to be NOT supported. For example, Oracle's "Compatibility Guide for Java 8" says things like this:
The com.sun.media.sound package is an internal, unsupported package and is not meant to be used by external applications.
The JDK internal package com.sun.corba.se and sub-packages have been added to the restricted package list and cannot be used directly when running with a security manager.
The apt tool and its associated API contained in the package com.sun.mirror have been removed in this release.
Conclusion, even if there is no explicit statement that com.sun.* packages are internal, Oracle is >>now<< treating them as internal when it suits them. In some cases, retrospectively.
As java programmers we have inherited a legacy app which is now being upgraded to java8. The App runs on an embedded jre which is shipped along with our App.
We also ship tools.jar with the App, which is used to:
1) Compile .java files at run time; e.g. com.sun.tools.javac.Main.compile("SomeCustomClass.java"...).
2) Process annotations using the apt tool( package com.sun.mirror.apt); e.g. 'int aptReturnCode = com.sun.tools.apt.Main.process(myAnnotationProcessorFactory...);
Problem is that the apt tool has been removed from tools.jar in java8 -> http://docs.oracle.com/javase/7/docs/technotes/guides/apt/GettingStarted.html#deprecated
and we cannot use some thing like 'JavaCompilerTool compiler = ToolProvider.getSystemJavaCompilerTool()' because we only have access to our embedded jre and no jdk on client systems.
As a workaround we are compiling the SomeCustomClass.java into a jar file externally and then adding it to our app's classpath but its not viable long term as these class's come from the client and can change all the time.
I can think of the following ways around this problem:
1) Ship 2 tools.jar an old one for annotation processing and one java8 for compiling code at run time, but no idea how to avoid any naming conflicts etc.
2) Rework the myAnnotationProcessorFactory code that is using annotation processing to use javax.annotation.* instead of com.sun.tools.apt.* . As this is legacy code it will be quite error prone.
Can you guys think of any other ways around it ?
Many Thanks
Could anybody explain what is the bytecode libraries? For example, some Hibernate 3.5 book tells me that Hibernate uses javaassit or CGLib bytecode libraries. For what this libraries exists? Thank you.
When you write a Java app, you have to compile with a compiler (e.g. javac) first. Some classfiles (*.class) are generated. There is the bytecode. The class file is a binary file that can be executed by a Java Virtual Machine.
You may want to read a classfile, modify a classfile (eg. for instrumentation) or create (generate) a completely new classfile. If you want to do this, a good library can make it easier. You don't have to care about the exact structure and many constants (e.g. opcodes).
CGLib homepage says that Hibernate "Uses cglib to generate proxies for persistent classes."
I notice a src.zip file containing some Java source bundled with the standard JDK install. When unzipped I notice C source files for the Java launcher, etc.
However, when I download the Java platform source from download.java.net/jdk6/source, I see a different folder structure and different files being laid down. Whats the difference between the two?
I want to recompile the Java launcher (rebuild java.exe using java.c). I can only find java.c in the src.zip file that is part of the JDK but not its dependencies. They seem to exist in the full source code bundle of the JDK. However, java.c itself seems missing in the full JDK source bundle. This is confusing to me.
Can someone please clarify the difference and how best to go about rebuilding only java.exe?
I assume that you are missing jni.h, etcetera. Take a look in $JAVA_HOME/include for the missing header files.
"The difference" is that the JDK that you download from the Oracle website is not OpenJDK. Rather it is based on the OpenJDK codebase, with a bunch of extra proprietary stuff.
It is your choice which one you use.