Shai Almog

This was raised in the manifold slack and it isn't as simple as one might think since null is deeply ingrained in Java.

I'm guessing one can use the expression language to write a slightly shorter syntax than the optional syntax but I'm not sure how applicable it would be.

The specific GraphQL docs are pretty lacking. Unfortunately, I don't have too much experience with GraphQL so I couldn't do their implementation justice. There's the sample app here: https://github.com/manifold-systems/manifold-sample-graphql-app/

But I would suggest asking in the slack channel as Scott is pretty responsive to queries there.

For most cases where we have a natural value for an object that isn't null we should assign it when creating the variable. This can be by making a field final and requiring the value in the constructor etc.

But let's look at the cases where there's no such "natural" non-null object. If we still choose to make the object non-null then we allocate a "dummy" object to serve as a placeholder just so we can discard it later.

The cost in performance depends on what the compiler will translate your non-null code to. In some cases this is translated to null but usually this isn't the case. Currently Optional has noticeable (albeit small) overhead. But other compile time options might not be able to use null in all the same cases. Non-null is an abstraction over null and abstractions tend to leak in unpredictable ways.

I meant Kotlins approach etc.

Not really because they didn't publish the final syntax but as far as we know it will only be a marker tag indicating that it will be non-null. As far as I understood enforcement at the compiler level won't be deep since they can't change libraries etc. Previously they had syntax that denoted this in the class level indicating that an object lacks "identity" which is a synonym to pointer.

Notice I mentioned that Valhalla will add a not-null marker which is important for memory layout. Yes, that should go into the language but it's a different thing from the systems used by other languages.

That's a great point. This indeed drew some inspiration for a trend of that time called "design by contract". That mostly focused on asserts but the idea was to map all the various ways the object can fail for bad input.

This is also very powerful in combination with JavaDoc.

Right, I meant to say code rot.

Unfortunately the links in the post were removed during editing. The original is here: https://debugagent.com/open-source-maintenance-is-community-organizing

Yes. I did mention the events but didn't want to get into the nuances of the implementation. Since it's relatively young, I'm not sure if it will be a decent replacement to Kafka but it is a very interesting project.

That's why I mentioned Lombok which is still applicable. Records are improving though.

I think the lambda implementation was a bit broken which is the one problem with checked exceptions. I blame the lambda, not the exceptions.

I agree, a lot of complexity was added but newer languages are even more complex and don't have the same level of functionality. With the exception of JVM languages.

I think everyone defines this a bit differently. There's also the quiet firing where bosses assign bad tasks and create an unpleasant work environment.

I picked the more widely understood version of quiet quitting: doing exactly what the job description says. No more. No less. It's a legitimate thing. What's interesting is that it's a change for a lot of people. Why would people change that behavior?

Because the dime dropped for a lot of them. They understand their employer will dump them in a heartbeat, regardless of how hard they work. No reason to go the extra mile. That's OK when talking about overtime. It's not so great if you don't document your code because well documented code isn't benchmarked in your quarterly reviews.

Great quote!
A boss should never demand loyalty. It's something that's earned.

I'm not sure if Lightrun fits into the "fight technical debt" but debugging production is pretty much a universal "fixer" problem. I think our plugin is probably one of the coolest around (in my not so subjective opinion): https://lightrun.com/

Great seeing your talks there!

Generally virtual conferences have a problem of audience participation. I noticed FOSDEM was MUCH better than the median cookie cutter conference in terms of participation. Not sure if it was due to the foojay room we were in or the conference itself though.

It took well over a month of work. The main work was around the deployment of the native libraries and a lot went into the media code so it would use CEF instead of the built-in APIs of FX. That required recompiling CEF for every platform which took a lot of effort. Steve Hannah did most of the work there. I can connect you to him if you're interested. You can see the stuff he did in our repo: https://github.com/codenameone/CodenameOne/

Did you two coordinate this?
https://dzone.com/articles/jxbrowser-and-javafx-webview

We use JCEF but played with JxBrowser in the past. It seems like an excellent solution. Since we're an open source project we picked CEF but it was a pretty challenging process.

It was an uphill battle too. We had to compile our own version of CEF because the default version doesn't include support for 264 playback. That took a lot of time and pain.

But the end result is a modern/consistent browser over which we have more control regardless of the underlying JDK. So it paid off. Removing the FX dependency is a huge advantage.

We chose to go with JCEF which is used by Intellij as well.

I very much agree with the UUID usage in DBs but some people don't: https://github.com/jhipster/generator-jhipster/issues/3060

To be fair, they are correct. There is a performance impact. I think it's something most of us can live with.

The common term is time travel debugging. E.g. https://www.replay.io/

Do you work for free?

Why do you expect professional developers who build tools to do what you don't?
If you can't spend on your craft then you're a hobbyist not a professional. When there's a better free product then I use it (e.g. Linux) but when the product delivers a lot of value over a free product then I make the calculation of my time that's saved. My time isn't free.

FYI If you mean "open source" then the core of webstorm is open source.

BTW Visual Studio Code also has a commercial portion that isn't "free"...

I think you should compare react native to Kotlin Native or Kotlin + Codename One.

FYI All of the 4 things you mentioned at the bottom of the article as downsides of flutter don't exist in Codename One plus a lot of other advantages...

I work with all 3 IDE's since we produce plugins for all of them. Eclipse improved recently but it still lacks some capabilities e.g. the debugger in IntelliJ renders values of variables next to the line where they are mentioned... Eclipse has some power but it's very "opinionated" this isn't necessarilly bad but it makes it harder for beginners.

I like some of the concepts of javafxpackager but from our experience with it I was pretty disappointed by the implementation. Its pretty buggy and spartan.

It seems that with every release of Java a new team comes along and completely reinvents distribution (webstart rewrites, Java plugin, packager etc.). The problem is that all of these approaches are damn awful. E.g. fxpackager needs both a Mac and a Windows machine. Signing (which is required on Mac OS) is a HUGE pain.

So FXLauncher looks promissing but the underlying fxpackager is the true problem.

;-)

I would use the analogy of a cleaning person picking up the garbage. So he first comes along to check if the garbage is used by anyone and places a yellow sticker on everything that's used. Then he indiscriminately throws away everything that doesn't have a yellow sticker on it.

GC's are actually remarkably simple, its the implementation that gets a bit tricky specifically in regards to threads...

You should note in the article that this process is illegal and violates Apple's ToS. I doubt this will ever reach a court case or even trigger banning but Apple doesn't allow Mac OS virtualization unless it is done on a physical Mac machine.

So this process might be reasonable for a hobbyist but its not something you should be doing if you work for a major company.

At Codename One we use Mac's that we host in the cloud for our service and will soon also offer support to automatically generate the certificates for them. We also use them for the xcode build process so the full package can be maintained and still be 100% legal.

You failed to mention Codename One which doesn't quite fit any of the categories you mentioned but being completely based on Java is probably more relevant to the java dzone readership than all of the tools mentioned in the report.