Support for package "com.ibm.misc" and its classes - java

I wanted to decode a Base64 string in my XPage for which I was using sun.misc.BASE64Decoder class. But according to Java developer should not write programs that call 'sun' packages. I was searching for an alternative when I stumbled on com.ibm.misc.BASE64Decoder. It worked for me with same results as sun.misc.BASE64Decoder. So I would like to know if it is okay for developers to use this package and its classes? Or is it to be avoided like 'sun' package?
Also I know that I can use Apache Commons for Base64 but I would like to minimize my dependency on external JARs.

With com.ibm.misc.BASE64Decoder you'll have exactly the same problem as with sun.misc.BASE64Decoder: it's an internal class which only exists in a specific JVM implementation, in this case IBM's JVM.
Note that there is no com.ibm.misc.BASE64Decoder in Oracle's JVM, so if you use this class, your program is not going to work on Oracle's JVM; it will fail with a NoClassDefFoundError.
You could use the method that mre refers to in his comment, which is in the class javax.xml.bind.DatatypeConverter - part of the JAXB API, which is part of the standard Java API (since Java SE 6).

Related

Workarounds to import java lib for mingw / ios / linus / other source sets?

I am aware that it's quite a weird use case to depend on having JVM installed for some OS source sets, allow me to go through my use case.
I'm writing a simple utility to wrap calls for the steamCMD (https://developer.valvesoftware.com/wiki/SteamCMD), which has platform dependent installation procedures. So, naturally I should have
// commonMain / steamCmdGetter.kt
expect interface SteamCmdGetter {
fun installClient()
}
// [OS] / steamCmdGetter.kt
actual interface SteamCmdGetter { /* ... */ }
On the other hand, my utility also needs to do work with the file storage (for example, downloading and checking client existence in storage), so I could also use a file class.
// commonMain / File.kt
expect interface File
I am aware that the JB team has an explicit recommendation on its tutorials.
We recommend that you use expected and actual declarations only for Kotlin declarations that have platform-specific dependencies. It is better to implement as much functionality as possible in the shared module even if doing so takes more time.
Yet, against the warnings I wish not to write a MyFile implementation to save efforts from reinventing the wheel for such a common task, but java.io.File has been so dominant in the scene that I could not find any Kotlin alternatives on Gradle / Maven.
Does this means I am forced to write MyFile in the end? Or is there a workaround for importing Java libraries to Kotlin MPP platform sourceSets?
First of all, one can use Java libraries only for jvm and android targets, not the others provided by the Kotlin/Multiplatform. In fact, this is exactly a targets subset that is using Kotlin/JVM. Neither Kotlin/JS nor Kotlin/Native provide interoperability with Java, they has their own interop capabilities. See this page to get some details on the difference. About working with files in particular. Most probably the answer is yes and you'll have to implement it per-target. This kind of work is usually platform-specific, as it hardly rely on the OS implementation. However, part of the functionality you search for should be definitely found in the platform.posix.* platform library, even if it would appear more C-stylish.
P.S. Quick search across the Web led me to this community libraries list, maybe it would help. Also, kotlinlang Slack community(find link here) may have some interesting solutions to share.

Java Bytecode Manipulation Without External Library

Libraries such as ASM, BCEL, Javaassist and AspectJ are all capable of runtime bytecode manipulation but how do they achieve this?
I have done some basic bytecode manipulation using ASM before but i don't understand how it works. Is the Java Agent executed in the JVM before the remainder of the program, allowing for ASM to load the compiled classes and edit them before they are executed by the JVM?
If so, is it possible to perform java bytecode manipulation without using an external library like ASM and loading the compiled class files with an BufferedReader and writing a custom parser etc. for example?
These libraries settle on standard Java APIs which, of course, you can also use yourself without these libraries.
First of all, Java class files are just sequences of bytes in a well defined format, as specified in JVMS §4, The class File Format. The primary task of the mentioned libraries is to provide tools for processing byte sequences in this format. The second is about getting the definitions of existing or exporting modified or newly created classes.
There are two different way of dealing with the second task. One is to read compiled classes from persistent storage like file systems or jar files, etc. and writing them back to these storage while the particular code is not running, like build and deployment tools do. This should be trivial, as it just boils down to reading and writing bytes.
The other is to manipulate classes at runtime, which can be done by Java Agents via the Instrumentation API. It offers mechanisms for intercepting classes at loading/definition time before their first use, but also redefinition of classes. The latter can’t change them freely, currently, it has to retain all field and method declarations, so it can be mainly used to change the executable code of the methods.
If you want examples for class file processing without additional 3rd party libraries, there are some answers on Stackoverflow
Extract the class name from a class file
Find all class dependencies
Parse the constant pool
Iterate over all instructions of a method
Of course, these examples are only single-purpose code or sketches. If you expand them to something more general or useful, you will soon end up at basically re-implementing these libraries.
Class files are just a sequence of bytes, the format of which is specified in The Java Virtual Machine Specification. BufferedReader is for text files so you'd want BufferedInputStream, but the format is quite complicated.
You can load manipulated class files as if they were generated by javac. You can also load them dynamically with java.net.URLClassLoader.newInstance or similar. Java Agent allows modification of class files as they are loaded, either through a Java or a native interface (the latter being necessary if you want to modify classes the are loaded before classes that load classes).
Recently java development group at Oracle announced a new JEP( Java enhancement proposal) for class file manipulation. Now we will not need any additional libraries.
https://openjdk.org/jeps/8280389

Class file parser

I have an assignment where i need to write a Java program that parses a .class file and retrieves things like :
1.name of the .java file
2.implemented interfaces
3.variables
4.constructors
5.methods
I don't have any ideeas where to begin from?
For example,what kind of Data I/O structure should I use?
You can you ClassParser which is available in Apache commons library. you can read the Javadoc here. You can download apache commons from here
You can also use Java reflection API which provides method such as getDeclaredFileds, getDeclaredMethods etc.
There are already several libraries for classfile parsing out there. Objectweb ASM is the most popular.
If you have to do it from scratch, that I'd recommend starting by the JVM specification, which explains the binary layout of classfiles in detail. After that, parsing is just a simple matter of programming. I've written a classfile parser before, it's not that hard.
You don't need any external library, just use java.lang.Class. Write the name of your class:
[NameOfMyClass].class.getDeclaredFields();
[NameOfMyClass].class.getDeclaredConstructors();
[NameOfMyClass].class.getDeclaredMethods();
It's the same for interfaces and many other attributes.
You can use Java Reflection. Here is a good tutorial -->
Java Reflection Tutorial
OpenJDK actually comes with an API that lets you parse and manipulate class files programmatically that most programmers don't know about. It is located at the package com.sun.org.apache.bcel.internal.

How to analyze method calls and objects of other classes used in a java class programmatically

i need to detect if a class relies on another class programatically,to detect inappropriate intimacy code smell(i want to analyze other java programs ,using my program).Any directions on
how to achieve this will be a great help.
And
How to identify all the objects created in a java program?
How to identify all the called methods in a java program?
Any help would be appreciated.
You might want to use what's already there instead of building something yourself. Especially if you're not very familiar with the internals of Java and the JVM.
Have a look at JDepend: http://clarkware.com/software/JDepend.html
Use a profiler as JConsole or VisualVM. With the use of profilers you can pretty much see everything that happens at runtime.
One way i think of is using logger, Put some log statement in the construct and in the methods you want to monitor. So through logs you can find out the objects created and methods accessed
I have found very useful the ObjectWeb asm-all Java bytecode manipulation and analysis library, also known as asm-all.jar
It allows you to convert any *.jar application into equivalent XML file. You can fully inspect the application structure, change it in the XML format and convert back into *.jar file
In order to use the XML files you'll need to understand what it contains. Oracle's The Java® Virtual Machine Specification is very good reference to start with
BTW: one thing you can do with this tool is to instrument the bytecode so that it creates runtime profiling information - which methods were called and by whom (as suggested by #upog)

Accessing Java annotations from a Taglet

I'm working on a project where we have some custom Taglet classes that are used to modify the Javadocs (such as linking to source code in SVN, adding citations) and so on.One of the things we'd like to do is to be able to get the annotations that are used in the source and manipulate the information from them.
It seems that the Taglet interface does not provide an easy way to access annotations in the Java source code. Does anybody know if this is at all possible?
I'm using JDK 1.5
If your taglet is called from the standard doclet, you can access its internal state:
import com.sun.tools.doclets.standard.Standard;
ClassDoc currentcd = Standard.htmlDoclet.configuration.currentcd;
I have written a Taglet that uses this technique, but it sure ain't pretty ;-)

Categories