I have this code `val pdfDoc = PdfDocument(PdfWrit...
# getting-started
j
I have this code
val pdfDoc = PdfDocument(PdfWriter(fileName))
but the implementation for PdfDocument is
Copy code
public PdfDocument(PdfWriter writer) {
        this(writer, new DocumentProperties());
    }
what is pdfDoc assigned to with no return value?
k
This is a constructor
👆 1
r
I guess pdfDoc is the object of the class PdfDocument
👍 1
k
Is this a Java code snippet, or a Kotlin code snippet?
a
This looks like Java
👍 2
k
I guess it is kotlin code using java lib 🙂
r
Yup., I'd guess the Java looks like this:
Copy code
public class PdfDocument {

    public PdfDocument(PdfWriter writer, DocumentProperties documentProperties) {
    }

    public PdfDocument(PdfWriter writer) {
        this(writer, new DocumentProperties());
    }
}
The equivalent Kotlin would be:
Copy code
class PdfDocument(
  writer: PdfWriter, 
  properties: DocumentProperties = DocumentProperties(),
)
Or if you wanted it to be the basically the same byte code:
Copy code
class PdfDocument(
  writer: PdfWriter,
  properties: DocumentProperties,
) {
  constructor(writer: PdfWriter): this(writer, DocumentProperties())
}
k
The way I read the question was that
public PdfDocument(PdfWriter writer)
doesn't seem to return anything - and that is true in the Kotlin world. But in the Java world that's the constructor syntax, so the "return" of that is a
PdfDocument
object
a
Wait, if you put a default value for an argument in the constructor it won't generate the same bytecode as two constructors with the second one using the default value for the argument ?
e
not quite, no
a
Why, and what would be the difference ?
e
without
@JvmOverloads
Kotlin generates a constructor taking every parameter, a bitmask of which parameters are present (or several, depending on how many arguments there are), and a DefaultConstructorMarker (for overload disambiguation)
a
Oh yes I remember now that it's doing that
e
very much not something that is intended to be used from Java
a
So by default it's not interoperable with Java
e
it's technically callable… but it involves too many low-level details that you shouldn't