I have this code `val pdfDoc = PdfDocument(PdfWriter(fileName))` but the implementation for PdfDocum...

# getting-started

[Jasin Colegrove]

I have this code val pdfDoc = PdfDocument(PdfWriter(fileName))
but the implementation for PdfDocument is

public PdfDocument(PdfWriter writer) {
        this(writer, new DocumentProperties());
    }

what is pdfDoc assigned to with no return value?

[Kirill Grouchnikov]

This is a constructor

[Rodrigo Bressan De Souza]

I guess pdfDoc is the object of the class PdfDocument

[Kirill Grouchnikov]

Is this a Java code snippet, or a Kotlin code snippet?

[Ayfri]

This looks like Java

[kqr]

I guess it is kotlin code using java lib 🙂

[Rob Elliot]

Yup., I'd guess the Java looks like this:

public class PdfDocument {

    public PdfDocument(PdfWriter writer, DocumentProperties documentProperties) {
    }

    public PdfDocument(PdfWriter writer) {
        this(writer, new DocumentProperties());
    }
}

The equivalent Kotlin would be:

class PdfDocument(
  writer: PdfWriter, 
  properties: DocumentProperties = DocumentProperties(),
)

Or if you wanted it to be the basically the same byte code:

class PdfDocument(
  writer: PdfWriter,
  properties: DocumentProperties,
) {
  constructor(writer: PdfWriter): this(writer, DocumentProperties())
}

[Kirill Grouchnikov]

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

[Ayfri]

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 ?

[ephemient]

not quite, no

[Ayfri]

Why, and what would be the difference ?

[ephemient]

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)

[Ayfri]

Oh yes I remember now that it's doing that

[ephemient]

very much not something that is intended to be used from Java

[Ayfri]

So by default it's not interoperable with Java

[ephemient]

it's technically callable… but it involves too many low-level details that you shouldn't