sunhttp does not work on native, it’s java only

# server

[gildor]

sunhttp does not work on native, it’s java only

[RichyHBM]

Aside from sunhttp does anymore of http4k-core depend on java?

[RichyHBM]

Thinking about just using that and once native IO/socketsbare in, write a native server implementation for http4k

[gildor]

I don’t know, but I think it’s not so easy to port big http library to native

[dave]

yes, it does. We'd like to rely on pure kotlin types for everything, but this just isn't practical. Here's a a list of the stuff the core prod code relies on currently

import java.io.ByteArrayInputStream
import java.io.ByteArrayOutputStream
import java.io.Closeable
import java.io.File
import java.io.InputStream
import java.io.PrintStream
import java.io.PrintWriter
import java.io.StringWriter
import java.lang.Exception
import java.math.BigDecimal
import java.math.BigInteger
import java.net.HttpURLConnection
import java.net.InetSocketAddress
import java.net.URI
import java.net.URL
import java.net.URLDecoder
import java.net.URLDecoder.decode
import java.net.URLEncoder
import java.nio.ByteBuffer
import java.nio.charset.Charset
import java.security.MessageDigest
import java.time.Clock
import java.time.Duration
import java.time.Duration.between
import java.time.LocalDate
import java.time.LocalDateTime
import java.time.ZoneId
import java.time.ZoneOffset
import java.time.ZonedDateTime
import java.time.format.DateTimeFormatter
import java.time.format.DateTimeFormatter.ISO_LOCAL_DATE
import java.time.format.DateTimeFormatter.ISO_LOCAL_DATE_TIME
import java.time.format.DateTimeFormatter.ISO_ZONED_DATE_TIME
import java.time.format.DateTimeFormatter.RFC_1123_DATE_TIME
import java.time.format.DateTimeFormatter.ofPattern
import java.util.ArrayDeque
import java.util.Base64
import java.util.Enumeration
import <http://java.util.Locale.US|java.util.Locale.US>
import java.util.Random
import java.util.UUID
import java.util.concurrent.ConcurrentHashMap
import java.util.regex.Pattern
import java.util.zip.GZIPInputStream
import java.util.zip.GZIPOutputStream

[dave]

although bear in mind that that is the entire of the core, including the lens system which uses a lot of the built in types for automarshalling queries etc. it would be a LOT less if you just took the basic concepts - probably just the primitives plus a couple of things like the InputStream for message bodies, or UrlEncoder/decoder

[RichyHBM]

@dave Have you thought if putting all the java classes behind an interface and then have the standard java classes implement that interface in an additional package? That way you could select to use the java or (once available) the kotlin variant

[dave]

We haven't, mainly for the amount of bloat that would currently add. Once Kotlin makes a reasonable (or even "an"!) option available in this space then we'll be moving towards that in order to make multi platform more viable.