In a static type system, all of the expressions and expression-like constructs of your language may have a constraint attached to them, which guarantees that a value this expression yields have certain properties; In a static type system there is a well defined set of rules, describing how such constraints are transformed when expressions are combined in a certain way.
In a dynamic type system, no such constraints exist (besides for the constant literals, of course) and there are no rules for combining the constraints.
This gets close but I think it doesn't yield a conclusion that Java is statically typed, and I think most people want a definition that concludes Java is statically typed.
(unless you allow only fairly trivial "constraints" in which case you're no longer distinguishing between categories of languages, since essentially any language can satisfy a trivial-enough constraint on its expressions)
I think it's reasonable to draw the line somewhere between Java and, say, Python in the kind of constraints that a type system can enforce. Java does not have a particularly sophisticated type system, but I wouldn't be surprised if I could get some reasonable help from it (I haven't written any Java in years, much Java in longer...).
Just remember that one of the reasons why the JVM does all sorts of fancy/mind-boggling runtime heuristics and optimizations is precisely because it's not possible, at compile time, to always determine a usefully-specific type.
(and to really go off the deep end, in Java it's not possible to determine even what the universe of possible types is at compile time, which is why I like it as a counterexample to people who think they can meaningfully define "statically typed" and have it manage to include Java)
> it's not possible, at compile time, to always determine a usefully-specific type.
You seem to be using "type" here to mean "runtime representation", which is a common use but is only one specific case of what is being discussed above. As I understand it (and remember that my Java is rusty), it is entirely possible to statically guarantee that whatever a given expression evaluates to, it satisfies a particular interface (moreover, it was deliberately labeled as doing so). That may not be "usefully-specific" for an optimizer (or more carefully, it may leave some vague that will be more usefully specified at runtime; we haven't established that the level of specification is of no use), but it certainly seems to be a constraint of the sort that sklogic was talking about above, and it seems like something that could be useful to me as a programmer.
I actually think that "representational types" - constraints that tell us explicitly about how the data is represented in memory - is the place where the dynamic typing languages got it right. As long as it's internally consistent, I don't care exactly how the data is laid out, and automatic systems can do a plenty good enough job figuring that out (except at system boundaries where I need to worry about interchange, or if I care an unusual amount about performance). If representation is not something I care about, I should not be wasting time/attention talking about it. Where, IMO, this goes wrong is overgeneralizing to say, "... and since that's all types are good for, types are not useful." That's not all types are good for.
> (and to really go off the deep end, in Java it's not possible to determine even what the universe of possible types is at compile time, which is why I like it as a counterexample to people who think they can meaningfully define "statically typed" and have it manage to include Java)
How is the same thing untrue of C? or Haskell? If I write code that interacts with data generated by a dynamically linked module, that data might include newly defined types. This isn't a problem for the theory - we've still internally verified the constraints we're checking in each module, and potentially also at the interface (depending a bit on ABI).
it certainly seems to be a constraint of the sort that sklogic was talking about above
Well, this is the thing. sklogic and others seem to think there's some sort of clear bright line dividing, say, Python from Java, where in Python they'll claim you can only deduce a constraint like "is of type object" ahead of time but in Java you can deduce something more specific.
And setting aside the falsity of that (even on Python 2, which doesn't have the annotation syntax or library support to do type hinting, you can still deduce a lot of specific information AOT), I'd argue with the concept of a clear dividing line and say instead that there's a spectrum. And I say this precisely because in languages like Java you can end up only able to deduce something will be of, say, type "Entity", which while better than "Object" still feels less like a qualitatively different thing to me and less useful for expressing the kind of rich constraints hardcore static-type folks talk about. Yet people seem to accept it as a statically typed language.
How is the same thing untrue of C? or Haskell? If I write code that interacts with data generated by a dynamically linked module, that data might include newly defined types.
It can happen in other languages, but Java specifically does a lot of heavy lifting to work around this kind of issue, and some of that is specific to the features and quirks of Java. There's a reason, after all, why people non-jokingly refer to the JVM as the best dynamically-typed language runtime ever developed.
But again what we end up talking about is less a clear binary of "this language is dynamic, that language is static" and more of a spectrum of different combinations of features and design choices which sort of gradually blend into each other as you look at them side-by-side. Which is why I like to argue with the idea that we can meaningfully define "static" or "dynamic" typing.
