Prerelease versions of JDK 7 contained a class java.dyn.InvokeDynamic that allowed creating invokedynamic instructions from source code.
See here:
http://fwierzbicki.blogspot.com/2009/08/invokedynamic-and-jython-part-i.html
In the official JDK 7 release this class seems to have disappeared. Does anyone know if this source-code option is still supported?
java.dyn package has been renamed to java.lang.invoke.
Though I don't think you can create the 'invokedynamic' instruction from Java, the instruction is there for other dynamic languages.
In Java you can use 'java.lang.invoke.MethodHandle' as a faster alternative to reflection, examples are available in the javadoc of the MethodHandle class. Note that invokedynamic instruction itself relies on MethodHandle for dynamic linking of methods. (For more details you can read Oracle's article New JDK 7 Feature: Support for Dynamically Typed Languages in the Java Virtual Machine)
Related
I need to connect native java libraries for use in the ios environment. In particular, it is necessary to use ready-made support for crypto libraries.
I tried using ikvm(.net core xamarin) for ios. but there is no support for mono-touch.
See this answer from the knowledge base.
You can't use an arbitrary JAR "as is". Please also check the maven dependency discussion in this post.
You can wrap libraries as cn1libs but a library might use arbitrary Java code which might be a problem, see this.
i am new to openJDK8, i want to locate the file(s) where the bytecode instruction set is present which is used to generate the bytecode of a source .java file.
Secondly i need basic knowledge of the bytecode generation and execution process.
i am a research student and working on openJDK bytecode. Can you please guide?
The question seems to be conflating/mixing a number of different things. If you are creating a new bytecode there's several things you need to do.
Specify/define the bytecode
Modify the compiler to generate that bytecode
Modify the runtime to understand that bytecode
The Java bytecodes are specified in the Java Virtual Machine Specification. If you need to define a new one, you need to specify it to a similar degree, though you don't have to publish it there.
The part of Java SDK that is responsible from taking Java source code and producing Java bytecode is the Java compiler (javac). The source code for OpenJDK's javac is available here. The source code for Eclipse's Java Compiler is also available, but I don't know where.
Once you have the java compiler generating your custom bytecode, you have to teach the JVM how to interpret it.
The OpenJDK VM (hotspot) has several components that handle executing the bytecode. There's more than one interpreter (that reads and executes bytecode) and multiple Just-In-Time optimizing compilers that read the bytecode and (possibly) compile it into machine code before executing it. The source code for all of them is part of the hotspot. You probably just want to limit yourself to the interpreter and disable the compilers for initial work. If so, this set of notes explain how the hotspot interpreter works.
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.
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 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 ;-)