needusername

> "foo IN (a, b, c)" can often be better done as "foo = ANY(ARRAY[a, b, c])" in Postgres - not least because you can shift to passing in an array of variable size without having to construct a special statement for each.

When using Oracle and the values are not static/a literal you should be using

    foo = ANY(SELECT column_value FROM TABLE(?))

with an array as a bind parameter. This saves on hard parses, increases the effectiveness of cached session cursors and any client side prepared statement cache.

No need to deal with vacuum and a lot of other performance related features.

A TIMESTAMP WITH TIME ZONE data type that makes sense and is usable.

Well they actively ignored his input:

https://github.com/tc39/proposal-temporal/issues/7

https://github.com/tc39/proposal-temporal/issues/84#issuecom...

I assume it doesn't help that Oracle is arguing in court that APIs should be copyrightable.

As a merchant you chose Wirecard because no other acquirer wants you business, see FriendFinder.

> Most applications do not contain JITs.

Java apps and JavaScript apps (Electron) come to mind.

Hell no. Seaside captures the state server side, stores it under an id and sends that id to the client. The client sends the id of the state snapshot back to the server.

> How is that related to memory allocation costs?

It's a cost that has to be paid when using bump pointer allocation.

> We are talking about the cost of obtaining a chunk of memory. The cost of actually creating an object is allowed to be much higher because constructors are allowed to execute any arbitrary code.

Accessing main memory is about two orders of magnitude slower than accessing L1. For that time you can run a lot of arbitrary code that accesses data in L1 and registers.

> Just think about how expensive it would be to allocate a 3d vector consisting of 3 floats with malloc() 20000 times and then later deallocate it. Nobody is worrying about the cost of writing 3 floats to RAM. Everyone is worrying about the cost of malloc traversing a free list and it causing memory fragmentation in the process. Meanwhile the arena allocator would be at least as efficient as using an array of 3d vectors.

malloc doesn't mandate free lists, other implementations exist. It's not about relative costs. OP claimed bump pointer allocation to be a "no-op" when it's clearly not.

No, in practice this is not true. You will also need to write out to memory all the newly allocated objects which you don't need anymore.

https://podcasts.apple.com/us/podcast/hidden-gc-bandwidth-co...

> memory allocation will become a no-op (= bump allocation)

No, that's a cache miss.

Nope, Apple Pay is EMV only.

Only Samsung Pay does magstripe emulation.

Sure you can. It's not a special case. That's the beauty of Apple Pay. Industry standard protocol. If the merchant accepts contactless credit cards then Apple Pay will work. No need for any special hardware, any special software or any contract changes.

> I haven't found a single debit card that works with it

Well yeah. Because the banks don't make money with debit cards so they do everything possible to sell you a credit card. That's why in Switzerland you have this special variant of a Meastro which you can't pay online. That's a special deal with Mastercard for Switzerland only because Mastercard generally doesn't allow blocking this.

They make it sound like there is a special "Apple sauce" that they built and strongly suggest they generate a new PAN for every transaction. The suggest that a "token" instead of a PAN is used for the transaction. This is very misleading. If you read it very carefully they are not wrong, but for the uninitiated a wrong impression is crated.

They are using an industry standard protocol that is 25 years old.

There is a lot of deliberately confusing marketing. "Tokenization" simply means that a new PAN is generated once per device. This is a normal PAN registered with the payment scheme and your issuer. It has to be a normal PAN, otherwise it would never pass through all the exiting payment infrastructure.

What is generated per transaction is the EMV unpredictable number, but this is part of the EMV protocol and done for any EMV transaction. Think of this like the dynamically generated symmetric key for an SSL session.

> It rolls a new number every time I use it, so i can pay at sketchy gas stations at 2 AM

Nope. That's deliberately confusing Apple marketing. You get one PAN per device. The new "number" is just the EMV unpredictable number. You get that with any EMV card.

https://emvlab.org/emvtags/show/t9F37/

> and not care about skimming.

Because the PAN is only valid for online authorized EMV transactions.

> but features some highly aggressive optimizations ideal for abstraction heavy code/languages (like scala).

Then native image may not be for you yet. Topline performance of native image is currently a lot worse than that of Graal compiler.

> Would be nice to use because scala generates garbage like it’s no tomorrow.

Then native image definitely isn't for you yet. The GC of native image is currently a lot worse than what you get with GraalVM / HotSpot.

One of the annoying things about Graal are there are a lot of different things all under the Graal umbrella. Also there are a lot of limitations of native image that people often don't talk about. These limitations basically make it not Java anymore. One person once summarized native image as, "even less Java than Android".

Yet any other OpenJDK distribution from Alibaba, Amazon, Azul, BellSoft, RedHat, SAP (I probably forgot some) all run the TCK. All except AdoptOpenJDK. And whenever you bring that up the only response is ranting about the TCK.

Honest question, do any of the current jClarity employees actually do upstream OpenJDK development? I know they build tools around Java but I'm not aware that any of the current employees take part in upstream OpenJDK development eg. at least have a JBS account. Maybe I'm just misinformed.

Yes, they do here

https://adoptopenjdk.net/upstream.html

Note that these are different binaries, build by RedHat not by AdoptOpenJDK. They are distributed there because the Java 8 and Java 11 OpenJDK projects are not allowed to post builds on https://jdk.java.net.

1. AdoptOpenJDK does not run the TCK.

2. Corretto and Zulu each have their own patch set. Corretto backports a couple of G1 fixes and Zulu backports Flight Recorder and TLS 1.3.

It should be noted that AdoptOpenJDK does not run the TCK against these binaries so they can not be called a compatible Java implementation.

They do not have a published list of requirements for Maven artifacts. This does not give a good first impression.

Do you see that it's disappointing that you can only give non-answers? The announcement does not mention what happens to your existing products and customers. You come here and offer to answer questions yet can't say what happens to your products and existing customers.

What's going to happen to Censum?

-XX is for implementation specific VM flags an generally uses + or -

-D is for system property and uses key value

so it would either be

-XX:+VerboseRuntime

or

-Djdk.runtime.verbose=true

Which turns to to be quite easy:

https://twitter.com/rafaelcodes/status/1125032183167688706

> Nobody actually cares about automagically storing value types in HashMap

I agree. When I look at the allocation profiles and heaps of our Java applications (which I assume to be fairly typical Java enterprise applications) boxed types do not show up. What really matters are Strings, both in the heap and the allocations.

To me this seems like a play against OpenJ9 which is at least partially based on OpenJDK. Rumor has it that AdoptOpenJDK lost their TCK license because they also published OpenJ9 builds.

I'm a bit surprised by this given that IBM is a long time license holder and I can remember JavaOne keynotes where Oracle celebrated IBM "joining" OpenJDK.