One thing struck me as a bit odd:
> In particular, it does not support: generics
What kind of support is there for generics in the JVM? Maybe I'm too naive to assume that due to type erasure on bytecode level everything is just an Object, ie. a reference type? Or do you mean the class definition parser - but then, you don't really have any checks in place to see if the class file is valid (other than the basic syntax)?
About the generics - some people have pointed out the same on reddit, and yeah, you are correct. The only thing that should be done is to read the Signature attribute that encodes the generic information about classes, methods, and fields (https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.ht...)
As a matter of fact, I just did a test and the following code works! :-)
public class Generic {
public static void main(String[] args) {
List<String> strings = new ArrayList<String>(10);
strings.add("hey");
strings.add("hackernews");
for (String s : strings) {
tempPrint(s);
}
}
private static native void tempPrint(String value);
}This is generated when you do something like: final Main value = list.get(0);
http://henrikeichenhardt.blogspot.com/2013/05/how-are-java-g...
OTOH lack of string interning is super strange [it's trivial to implement], and w/o it JVM is not a thing. String being equal by reference is important, and part of JLS.
Lack of thread makes the entire endeavor a toy project.
But, as the previous commenter attempted to point out to you this project is a *self-described* toy project.
On the very page that is linked, the author of the JVM specifically says:
"I want to stress that this is a toy JVM, built for learning purposes and not a serious implementation."
Thus, absolutely no one disagrees that its a toy JVM. They just want you to stop being dismissive of someone's toy project by repeatedly pointing out its a toy project and not a "not a thing"
SQL (ACID) over multiple non-cache-coherent nodes is extremely difficult to pull with regards to consistency, though.
Thats... why it's a toy! I'm really not sure what you're missing here.
> Moreover, a string literal always refers to the same instance of class String. This is because string literals - or, more generally, strings that are the values of constant expressions (§15.28) - are "interned" so as to share unique instances, using the method String.intern.
And later:
> Literal strings within different classes in different packages likewise represent references to the same String object.
Source: https://docs.oracle.com/javase/specs/jls/se8/html/jls-3.html...
But that does - as far as I can see - say nothing for non-literal strings.
[edit]: formatting
Nothing much to think -- distinct objects must have distinct references [e.g. new String("a")!=new String("a')], literals must have the same references for the same values [e.g. "a"=="a"].
if("abc" == "abc") { System.out.println("correct"); }
if(new String("abc") != new String("abc")) { System.out.println("correct"); }
> say nothing for non-literal strings
yes, of course.
https://docs.oracle.com/en/java/javase/11/docs/api/java.base...()
Also interning strings to optimize equality checks to be able to use pointer comparison is dangerous for external inputs since iirc at some point interned strings could permanently be stored (unless implemented by a WeakSet) and attackers could fill up your heap (or cause other GC issues since the entire interning functionality is a cache) by filling up your interning lists with crap.
I never said String must be equal by reference when their content is. However string literals must be equal by reference. I thought Mentioning the JLS would make it obvious, esp. having 'intern' in the context
Not certain about whether `String.intern` is permanently stored; I rather suspect that it sweeps the existing strings since iirc the java string has a hash associated with it anyway.
yeah, as stated by the author in the line that says "I want to stress that this is a toy JVM, built for learning purposes and not a serious implementation."