The Clojure test.check library includes an immutable version of the functionality provided by the Java SplittableRandom class, as described by Gary Fredericks in his "Purely Random" talk. However, the API docs for test.check exclude the clojure.test.check.random namespace in which this functionality is implemented. Is this namespace meant to be used directly from code outside of test.check, or should it be treated as an implementation detail and not used in that way?
Related
Within a custom Quarkus extension I would like to integrate an existing java library that currently is not compatible to Quarkus.
Are there any examples for the following use cases:
remove a java class from a dependency library (library is referenced as maven-dependency)- In this case I'll provide a compatible implementation within the runtime-module.
replace specific parts of an existing class form a dependency library (e.g. a default implementation of an interface)
Thanks, Thomas
For the first case, you can use a io.quarkus.deployment.builditem.RemovedResourceBuildItem to have Quarkus essentially remove a class from a dependency.
For the second case, you'll likely need to use a io.quarkus.deployment.builditem.BytecodeTransformerBuildItem which lets you declare an ASM class transformer which can change a class in arbitrary ways.
If you are only looking to change the class for native mode, it's much easier to instead use com.oracle.svm.core.annotate.TargetClass and com.oracle.svm.core.annotate.Substitute.
What exactly is the Hidden Classes feature in Java 15 ?
As i read in Java 15 documentation , Spring & Hibernate frameworks used Hidden Classes ? I need real example to Spring and/or Hibernate used Hidden Classes .
To answer this question, it's important to first distinguish the Java language from the Java runtime. The former is the "Java code" a programmer writes, while the latter is the "Java program" people use to run code written in that language (among other languages, like Kotlin and Clojure).
In the Java language, there are many ways to define a class. Most classes are like ArrayList, which are top-level and have a programmer-defined name. But other ways of defining a class may not have a simple name. An anonymous inner class, for example, does not provide a way for a programmer to give it a name. The same goes for lambda expressions introduced in Java 8.
In the past, the Java runtime has had the limitation that all classes must have a name and must be publicly addressable by the runtime. This has meant that the Java compiler gives an anonymous inner class a name unlikely to conflict with any other class's name, usually with dollar signs, which are legal class names to the Java runtime, but illegal class names in the Java language. This is an implementation detail. But because classes all have names and are all addressable through the class loader, abstraction is "leaky"; there are ways these classes which may be meant to be hidden can be addressed through access to the class loader.
"Hidden classes" are a new (to Java 15) feature of the Java runtime, a way for programs to define classes that cannot be addressed by other classes running on the class loader. They still have names, but access is scoped in a way that their existence cannot be "leaked" to other parts of the program. It is not a new language feature, but a tool that a compiler (or runtime framework) may use to implement certain pre-existing language features.
To the typical Java programmer, this process is transparent. Unless your program compiles code or manipulates bytecode, you do not need to worry about this implementation detail. But for those who do, this is a valuable tool in their software toolbox.
I want to write an RMI library in/for Ceylon (since I have not found one so far).
The first thing I need is a proxy. In Java I used something like
Proxy.newProxyInstance(classLoader, interfaces, handler);
1. Is there something equivalent in Ceylon? (haven't found something)
Attempting to write something like this my own, I came across this solution for the JVM using byte code manipulation.
Nifty and exactly what I want.
Notice, that this can even produce a proxy for a class, not only for interface like in Java. In Ceylon this is should be legit, since there are no fields and we can simulate the whole class with method calls.
2. If creating proxies for classes is a no-go just tell me.
Also, what is the Ceylon intuition/future about proxies? Shall there be (no) proxies?
In a future with proxies we have one major problem:
In Ceylon we have the default keyword, without it a method can not be refined/overwritten. This also results in final methods for the compiled Java output classes. Thereby (not even) the byte code manipulation can overwrite those and redirect them to an invocation handler/interceptor.
3. How do we deal with this?
I assume not at all? I totally get the idea of disallowing the refinement of methods and the default/final keywords, but this obstructs RMI/proxies for classes.
4. Are proxies for classes a bad idea?
And yes, there are so much more questions I am currently thinking about and investigating on: JS implementation, interfaces and default methods, etc
These points seem to be the most relevant at the moment, so let's start here.
You could try using this module I wrote:
https://github.com/gavinking/ceylon.proxy
Alternatively, if you're only targeting the JVM, you could just use Java's Proxy directly.
During further research I found:
1. Proxies are currently part of the Ceylon 1.4 milestone (issues regarding proxies).
3. Enabling EE mode for the ceylon compiler, removes the final keyword.
From this point on the solution I found works like intended and is exactly the same as the one provided by Gavin.
Don't the default Java access modifiers (public, protected, private) already define boundaries for how classes can be accessed. Why are these modifiers not sufficient? Why is OSGI's way of "defining moudle boundaries" better than this?
Yes, the java access modifier's define a classes boundaries and to some extent a package's boundaries but a module is larger than a single class or package. You may want to see http://www.slideshare.net/bjhargrave/why-osgi which explains the progression of encapsulation through classes and onto modules.
Short answer
In a modularized system it is very important to separate API from implementation where only API is exported. You cannot do that based on class modifiers. Other very important part of OSGi is the versioning of packages. You have to assign version only to those packages that are exported.
Long answer
A more prcise answer to this question is available at the following wiki post that was written by Neil Bartlett: http://wiki.osgi.org/wiki/Export_Only_APIs
Similar question
Why do we need object-orientation when functions are already available in structured languages? Are not the functions used to separate logical units of an algorithm?
I thought about it a little bit, and realized that there are certain privacy restrictions that OSGI's export mechanism can impose that plain old Java access modifiers cannot. See the diagrams below.
Notice how in Plain Old Java, a public class is visible (indicated by a green arrow) to all classes no matter what. In OSGI, a public class is visible to all classes (including classes in another bundle) ONLY if it is part of an exported package.
Note:The "protected classes" in the diagram are really just classes without any modifier (since there is no "protected" modifier for classes, just for fields and methods)
Edit: I'm adding this relevant quote from here: http://njbartlett.name/files/osgibook_preview_20091217.pdf
"A public class is visible to every class in every other package; a default access
class is only available to other classes within the same package.
There is something missing here. The above access modifiers relate to visibility
across packages, but the unit of deployment in Java is not a package, it is a
JAR file. Most JAR files offering non-trivial APIs contain more than one
package (HttpClient has eight), and generally the classes within the JAR need
to have access to the classes in other packages of the same JAR. Unfortunately
that means we must make most of our classes public, because that is the only
access modifier which makes classes visible across package boundaries.
As a consequence, all those classes declared public are accessible to clients
outside the JAR as well. Therefore the whole JAR is effectively public API,
even the parts that we would prefer to keep hidden. This is another symptom
of the lack of any runtime representation for JAR files."
I'm trying to understand where Spring custom namespace can help -- like simplifying somethings in a large application.
The last comment on this blog was intriguing:
I'm building out a namespace at work for making service and bean management more standardized within the development group. This also tends to make things simpler and not have them worry if I change the standard for a bean definition or maybe use different factories for different types of services in the future. I'm still figuring out how to best utilize this new mechanism, though.
Trying to understand how custom namespace helps in bean management.
If you developed custom namespaces, could you please post how custom namespaces helped in your development.
This blog has a great post about using custom namespaces and gives you a few examples as well.
Check this github repo for a working example of spring's custom namespace handling.
Or this article on spring io.