API differences in Hibernate ORM 5.1 vs 5.3
by Gail Badner
Hi,
There were lots of differences in the compatibility report, so as a first
step, I've excluded packages/classes that I considered SPI, internal, or
"grey area". This reduced the the differences to a more manageable amount.
You can see a summary of the incompatibilities along with suggested
mitigation at [1].
The report is attached to [1], along with a zip with instructions for
running the report.
I believe there are some "false positives" in the report, and I have
documented them in the section, "False Positives?".
Feel free to comment on the article.
Thanks,
Gail
[1]
https://developer.jboss.org/wiki/HibernateORMBinaryCompatibilityBetween51...
3 weeks, 5 days
IP banned from forum
by Gunnar Morling
Hi,
Is anyone banning users from the forum? I am getting "A ban has been
issued on your IP address."
I don't think banning by IP is a good strategy as many users will have
dynamic IPs from their hoster's shared pool, so it's a random game to
hit an IP previously banned due to some other user's spam.
Thanks,
--Gunnar
3 weeks, 6 days
New CI machine preview
by Sanne Grinovero
You're all welcome to play with http://54.225.162.168/
however please keep these in mind:
- it's not the final machine: don't put too much effort in creating
nice build scripts as we'll reset it to clean state soon. We *might*
be able to store jobs defined so far, but we might choose not to.
- domain name should be coming: ci.hibernate.org ..not sure when, got
no replies so far from.
- authentication: just click on login, it will use OAuth2 to request
your identity via your GitHub account. Permissions to create new jobs,
edit existing jobs, run a build manually depend on your github account
be part of the Hibernate organization (or not, in which case you have
read only status)
At this stage I'd like to get a feeling if the hardware is powerful
enough, and also we need to select which other plugins we want to use,
I'm looking especially to:
- static analysis reports
- pull requests integration
both are relatively undefined, we can of course start simple and
improve later.. just checking this fits basic needs now.
Sanne
3 months, 1 week
What does CacheConcurrencyStrategy.NONE mean?
by Guillaume Smet
Hi,
Does setting @Cache(usage = CacheConcurrencyStrategy.NONE) on an entity
mean that we entirely disable the 2nd level cache for this entity?
The documentation does not reference this value and the Javadoc does not
state clearly that the cache is disabled with this concurrency strategy.
Asking that because of:
- https://hibernate.atlassian.net/browse/HHH-12587 - where Chris disabled
writing to the cache in this case to fix a NPE;
- https://hibernate.atlassian.net/browse/HHH-12868 - where we have the
exact same NPE when reading from the cache.
The fix is easy if it's just about disabling the cache in this case but
maybe we should update the Javadoc of CacheConcurrencyStrategy if it's
about disabling the cache entirely?
Thanks for any insight!
--
Guillaume
7 years, 6 months
Stride
by Steve Ebersole
I got an email from Atlassian this morning about the migration from HipChat
to Stride. Basically they have not gotten Stride feature-complete in terms
of HipChat which is the trigger for the mass migration. However, they are
reaching out to all waiting teams to see if any want to migrate anyway.
The list of missing features they sent me are:
1. Guest access
2. Some admin controls and compliance settings
3. Integrations with Atlassian server products (the Jira Server app is
currently in beta and coming soon) and some other popular integrations. See
all available Stride integrations
<http://click.mailer.atlassian.com/?qs=6712850cb7a4f2d4a207f46e5f190a45485...>
.
4. User management via API
5. Dark mode
I am not really sure exactly what is missing WRT (2). (3) is nice-to-have,
but not blocker IMO assuming it gets added at some point.
I think (1) is the only one that is concerning. Though TBH for myself
personally, I do not think registering is a big deal.
Unless I hear otherwise, I plan on asking them to proceed with our
migration to Stride.
7 years, 6 months
ComplexStuff.INSTANCE : not always an efficient pattern
by Sanne Grinovero
Hi all,
I'm seeing plenty of code has been refactored in recent years to use a
" public static final X INSTANCE" field rather than a normal
constructor.
Often this is a good thing since memory allocation rate is *typically*
our limiting factor to improve performance, yet let's be mindful that
this pattern has some drawbacks as well.
An example is bootstrap code: if ComplexStuff.INSTANCE is used only a
very limited amount of times, and during bootstrap, having it in a
static final field will ensure that the memory of this instance is not
going to be freed up after it is no longer needed.
A similar pattern is to declare a Logger in a class as a "static
final" yet only ever use it in a catch block which is only going to be
executed to log a critical bootstrap error.
The Logger instance is taking quite some memory as well, so it would
be best to just create the Logger on the fly within the catch block,
essentially betting that this is either never going to be used (or
when it's used we want to crash fast anyway).
On top of memory usage, there's also the actual time it takes to
initialize such things; if it's rarely used, let's not use the static
final field as it enforces it to be initialized even when unnecessary
(unless being very careful).
Of course in most cases this makes no significant difference, so
should not worry anyone, but in some cases thinking about the
tradeoffs of such patterns can make a very good impact on overall
memory needs; e.g. I just removed a single singleton and this saves me
~20% of the overall memory during a bootstrap efficiency test.
hope you find it interesting!
Thanks,
Sanne
7 years, 6 months
