Ever asked yourself why the JDK isn’t shipped with a builtin base64 encoder/decoder? Well, since JDK 6 there is one – although it’s quite buried: javax.xml.bind.DatatypeConverter.
Usage is quite simple:
// encode byte[] to base64 String
String myBase64String = DatatypeConverter.printBase64Binary(myByteData);
// decode base64 String to byte[]
byte[] myByteData = DatatypeConverter.parseBase64Binary(myBase64String);
So no need to add a thirdparty library just for decoding/encoding base64 anymore.
Ever wondered why you get an IllegalAccessError when invoking protected/package-private methods on class B from class A although both classes are in the same package?
Well it mostly happens only at runtime when two different classloaders loading the classes. classloader A loads class A, classloader B loads class B. Since the JVM spec, paragraph 5.3 mandates
At runtime, a class or interface is determined not by its name alone, but by a pair: its binary name (§4.2.1) and its defining class loader. Each such class or interface belongs to a single runtime package. The runtime package of a class or interface is determined by the package name and defining class loader of the class or interface.
the package from class A is the same as class B at compile time, but NOT at runtime since it was loaded by different classloaders! To get to the root cause, you have to check why your classes are loaded by different classloaders. For example I came across that [link id=’153′]problem when using JBoss 7[/link] the first time.
At my company we’re starting to use JBoss 7.1 and came across a problem with its new classloading behavior. We’re deploying an EAR with the following structure:
EAR
lib
common.jar
ejb.jar
In common.jar are classes included, that have a package-private constructor that should only be used within ejb.jar’s factory. For this the factory and the specific classes are located in the same package, but in different jar’s. So a client can only use the public constructor of the classes whereas the ejb.jar can invoke the internal contructor not visible to the client.
With JBoss 5.1.0 this worked without a problem. But when we tried the same with JBoss 7.1, we encountered the following Error:
Caused by: java.lang.IllegalAccessError: tried to access method CommonClass.<init>()V from class FactoryClass
This is due to the fact that with JBoss 7 each jar is loaded by a separate classloader. We tried the suggested workaround using the jboss-deployment-structure.xml mentioned in a similar JIRA ticket, but always ended up in two separate classloaders for the jar’s.
Since it is a [link id=’170′]limitation of the underyling JVM[/link] and not JBoss 7 we simply added the factory to the common.jar and created a common-client.jar via maven assembly where the factory is excluded. Not nice, but helped us to go on.
When using Hibernate it quickly comes to the point, where you have to decide how your @Id attribute of your entity should be generated. JPA offers four possible options
If you have decided to take IDENTITY or SEQUENCE in the past, this can be a problem when supporting new databases in the future. Sadly, most of the databases don’t support both GenerationTypes. That is a bummer, because you have to decide early during development which GenerationType to choose. No matter which you’ve chosen, it’s the wrong one if it’s not TABLE or AUTO :).
Wie schon auf zahlreichen Seiten beschrieben, sollte man relativ einfach ein altes Google Analytics Konto mt einem neuen zusammenführen können. Grob sind folgende Schritte notwendig:
Anmelden an das alte Konto
Auswahl des zu übernehmenden Website-Kontos (falls mehrere vorhanden)
Unter der Tabelle “Websiteprofile”, ziemlich mittig platziert, auf “Nuzermanager” klicken
Dort rechts oben in der Tabelle “Bestehender Zugriff” auf “+ Nutzer hinzufügen” klicken
Dann unter “E-Mail Adresse” die des neuen Accounts eintragen und bei Zugriffstyp “Kontoadministrator” auswählen
Anschließend “Änderungen speichern”
Klingt doch einfach – soweit die Theorie. Weiterlesen…
Ich habe Ende letzten Jahres nach einem 18″ Notebook Ausschau gehalten um meinen Desktoprechner, mehr oder weniger, portabel zu haben. Dabei ging es eher um regelmäßige Wochenend-Trips und weniger um die tägliche Reise.
Da das Notebook hauptsächlich für die Software-Entwicklung zum Einsatz kommen sollte, musste es ordentlich Dampf haben (mind. 4 Kerne) und ausreichend (>4GB) Speicher besitzen. Ein größtmöglicher Bildschirm war obligatorisch, Grafikkarte spielte eine untergeordnete Rolle.
Mit diesen Eckdaten war es relativ schwierig Alternativen < 1000 € zu finden. Auch heute sieht es relativ übersichtlich aus:
Aufgrund der guten Rezensionen des Asus X93SV-YZ225V wollte ich dieses kaufen. Allerdings war das Notebook mehrere Wochen bei Amazon und anderen Anbietern nicht lieferbar. In lauter Verzweifelung bin ich dann zum Media(DAU)-Markt gefahren um dort, zu meinem Erstaunen, ein baugleiches Modell aus der A93S Serie vorzufinden: das hier beschriebene Asus A93SV-YZ222V. Alle Eckdaten stimmten mit dem Asus X93SV-YZ225V überein. Der Unterschied zwischen dem X93S und A93S Modell kann also eigentlich nur im Marketing vergraben liegen.
Also entschloss ich mich, dieses für den gleichen Preis gleich mitzunehmen. Jetzt, 4 Monate nach dem Kauf, bin ich immer noch begeistert von dem Teil!